When, and how, do we work together?
Cultural osmosis feels inadequate.
In my continuing quest to find constructive uses of AI, I’ve been reading a lot about how there’s a stratum of mathematicians who feel AI is not only helpful, but a harbinger of how math will operate in the future1. One comment in particular struck me, that “some math problems were more amenable than others to being solved through large-scale collaboration.” This naturally gave me pause and forced me to ask whether this is true for us in cybersecurity and privacy.
Of course, we don’t often talk about our challenges as “problems to be solved.” Instead we have threats to be mitigated, or organizational hurdles that interfere with our ability to implement those mitigations. In earlier posts, I’ve talked about developing a research program for higher education cybersecurity, and I’ve provided my own list of open questions that I believe if resolved, would help steer the field’s progress. But in this post, I want to explore the question of whether some of our challenges truly are more amenable to being collectively solved, or if they are so locally constrained that collective action is unnecessary.
At first glance, I think the heuristic here is pretty straightforward. Collaboration pays off when the problem is shared across organizations, that is, it has a kind of shared exposure. Perhaps from the same technology and same dependencies. Of course there are problems wherein no one sees the full picture; the image only truly develops when information from disparate perspectives can be sewn together. It should be obvious that anything with network effects benefits from aggregation - the value of the analysis or detection likelihood only increases with participation. And lastly, wherever the attackers scale across victims, i.e., adversarial reuse. All of these are familiar to anyone working at any organization with disparate units.
On the flip side, some problems appear to be solvable without any broad collaboration. I would call out local architecture decisions, or organization-specific risk tolerance and governance matters. And with highly sensitive vulnerability details, collaboration can introduce noise, delay, or risk exposure. But I did say “at first glance.”
As I’m writing this, I’m comparing it to my personal lived experience. Like most professionals, I’ve found sharing and listening to others - be it through a message board, mailing list, or hallway chatter at a conference - to be incredibly helpful. Ironically, it may be more helpful in those items I initially called non-collaborative. Who hasn’t spent time describing a difficulty they’re having with a governance committee, or a local architectural challenge with colleagues? These conversations do normalize practice across the field, albeit slowly. This is more through a kind of diffusion of practice - a passive leak of ideas - rather than a structural adoption of an engineered solution.
But I want to differentiate this kind of collaboration (perhaps snarkily labeled commiseration) from working collaboratively to solve a problem. Perhaps the distinction is therapy versus engineering. Both are helpful in moving you forward, but only one resolves an issue in a repeatable and codifiable way. There’s probably some wisdom here in watching out for the category error of “feeling supported” with “building a defense.”
The first example that comes to mind, of a problem that meets all four dimensions of the collaborative heuristic is building a network border2. Practitioners from outside of higher ed are going to read this and think we’re nuts for ever having to debate it. The traditional functional model many of us have settled on is roughly this for network ingress:
Internet → IP black hole service → firewall → IPS
Ah, I’m feeling nostalgic for simpler days. As anyone who’s older than my dog knows, the scars we earned arguing for that border firewall run deep. At many schools that battle continues because of either cost or arguments about academic freedom3.
But the idea of a network location being a control plane has been eroded to the point of near irrelevance. Increasingly we now think of the network border as porous and dynamic in that it’s highly distributed across cloud, SaaS, your legacy Internet border and endpoints. The border has become secondary to identity and policy enforcement. Of course, what’s interesting here isn’t just what the border is, but how visibility and enforcement move as the notion of a border dissolves4. Even as the border dissolves, the need for a shared model increases, not decreases. Examining this through the lens of the heuristic I provided above we see a distinct contributing factor, that is, shared technology and exposure. Most of us are wrestling with this same challenge and with the same vendors. By the heuristic I outlined earlier, this is exactly the kind of problem that should converge under collaboration. And yet, it hasn’t.
It’s clear to me that we lack some agreed upon approach to this problem. We could look at some of the canonical docs on network protection (e.g., NIST SP 800-41, NIST SP 800-53 SC-7 or AC-4 and of course NIST SP 800-207 which explicitly critiques and evolves beyond perimeter-based models), and I know many of us individually do. But I just don’t see anything passing as a community adopted model. We have references, but not a model. Guidance, but not convergence. Perhaps that’s because we are so loosely federated, there truly is no hub; it’s all spokes.
Equally as possible it’s because we’ve embraced a tad too eagerly the general belief that we’re all special snowflakes. “That model may work for them but they’re richer, bigger, smaller, poorer, less experienced or important than we are.” As idiosyncratic accretions of personalities and preferences, we are all special snowflakes. But I’d like to believe a perimeter is a perimeter (even if we’re abandoning the notion of one).
So we have these canonical architectures, we have decades of experience and shared practice, we’ve had time and commonality to figure this out, yet we haven’t converged on a solution. While it’s true the problem changed shape, it still remains shared. Yet despite everything, we behave as if the problem is local. Perhaps the fundamental issue is that we are treating a collective engineering problem as if it were a local architectural preference.
I suppose we should also ask: are the problems we need to solve in cybersecurity “solvable” in the same fashion as the math problems that kicked off this exploration? We know that a mathematical proof can be solved in more than one way (although often one method turns out to be the same approach in merely a different guise). But unless an error is found, a successful and complete proof is a statement of a kind of truth. The Pythagorean Theorem is a statement of fact: the square of the longest side (the hypotenuse) is equal to the sum of the squares of the other two sides. Is this kind of permanence true for us? Are our challenges truly solvable or merely “solvable given what we currently know of the threats and attack methodologies”?
Mathematicians solve for eternal truth, while CISOs only ever solve for time5. I suspect, sticking with the mathematical flavor, we could posit something like a theorem of cybersecurity depreciation. In cybersecurity our solutions are all born with a half-life. Naturally, this half-life cuts both ways. The ephemeral nature of solutions would seem to work against the value of creating a codified repository - why spend the time to polish and codify something that will immediately begin eroding? Whereas it also suggests that collective intelligence - collaborative analysis and maintenance - would help identify when a solution’s time is up, so to speak.
Another element that stands out in the writing on AI and math is how so much of the work is focused on either discovery or fragmentation. In some cases, an AI is used merely to offer up novel approaches to problems; in others, such as the Quanta piece I cited, the work begins by breaking a problem into a large number of smaller pieces, lemmas, the atomic components of the larger molecule of the theorem. It’s tempting to think that the market is taking care of the latter for us. Every vendor tackles each functional component as an element to be optimized. However, even in integrated solutions, such as nextgen firewalls that combine traditional firewalls and IPS functionality, that integration is more of a papering over of the edges. The UI tries to smooth over the reality that you have two products in the same chassis. These don’t solve a single problem, but present several solutions that are conveniently bundled into one SKU6. It’s tempting to argue that attackers optimize for reuse while defenders optimize for procurement.
At its core, math’s use of AI involves breaking a problem into its atomic components, which are individually proved, then recombined to form stable truths. Whereas in cyber, vendors control the decomposition, but no meaningful recomposition takes place, and what results we have rust over time. Addressing this may be much more impactful than any specific engineering-centric challenge we face. What would decomposition and recomposition look like for cybersecurity problems, and how do we recapture this space from the commercial marketplace - or at least influence it?7
I’ve been overextending the network border challenge but I can think of a few other narrower examples. For instance, if one university sees a handful of suspicious emails and another sees similar domains registered while a third observes credential harvesting endpoints, each sees mere noise. But collectively we see an early-stage phishing campaign developing. Thus, this meets heuristic number two, distributed visibility. Only by working collaboratively does the full image resolve as the telemetry is correlated.
Similarly, ransomware attacks seem to fit heuristic number four, adversarial reuse, whereby the attacker scales across victims. With most ransomware we have the same tooling reused. I’m thinking of highly commoditized frameworks like Cobalt Strike, credential harvesters like Mimikatz, and living-off-the-land binaries. It’s common to see the same attack chain, from phishing to foothold to privilege escalation to backup targeting. And of course, they show the same monetization patterns at each victim. After all, attackers want reuse because it lowers their cost. That means, however, that defenders can amortize detection and response across victims. Thus, we develop a shared understanding of the entire detection chain, not merely IOCs. This should lead to shared incident response playbooks, and preemptive control placement. But again, only with aggressive collaboration.
All of this is to say, that while vendors sell individual, fragmented lemmas (SKUs) that offer cosmetic integration, the actual threat landscape is highly integrated, repetitive, and optimized for scale. If attackers are amortizing their costs across victims through reuse, defenders are practically committing malpractice if they don't amortize their defenses through collaboration.
So why is it that despite our shared ecosystem, our shared experience, our shared references (NIST et al), we lack shared synthesis mechanisms? Why is it that within the institution of higher education cybersecurity practice, there is no institutional mechanism for turning shared experience into shared architecture? Lord knows it’s not for a lack of venues. We have consortia and conferences, national, regional, and local; we have all the modern tools of communication and collaboration available to us, yet with few exceptions we lean into commiseration and cultural osmosis over engineering8.
The wisest manager I ever worked for once, no doubt when I was justifying some procrastination on my part, dope slapped me with “people do what they want to do.” Advice that helped me be a better manager myself, but forced me to do some serious internal reflection on my own decisions. Which returns me to my opening question: Which problems should be collaboratively solved - and what should we do about it?9
To be sure, the broader barriers to collaboration often appear structural. We look at the landscape and notice a missing hub - the lack of a dedicated project owner or central catalyst to drive a community-wide initiative. But this absence is largely self-inflicted. In higher education, we wear our decentralization and institutional federation as a badge of honor, and we project that fierce independence onto the very organizations we establish to help us. Consequently, our collective bodies are designed more to facilitate polite communication than to execute rigorous collaboration.
Similarly, our lack of common metrics is a calculated omission. Defining hard security metrics is notoriously difficult, but it also threatens to decrease our local degrees of freedom and challenge our subjective preferences. Even our shocking lack of an agreed-upon, curated repository of solutions is less a resource constraint and more a defense mechanism. I view all of these structural gaps not as the root cause of our failure to collaborate, but rather as the visible artifacts of our unwillingness to converge. In the end, we do what we want to do.
I’ve provided a simple heuristic for evaluating challenges, but I suspect the failure to build a collectively engineered defense is fundamentally a failure of will and culture. In our relative isolation, it’s simply too easy to forget that the larger culture of our profession isn’t something that exists independent of us. Culture is an emergent artifact of the millions of small choices we make in our daily lives. We choose our own wardrobe. Perhaps we are also choosing fragmentation over convergence.
For a popular and digestible read on these issues, see https://www.quantamagazine.org/how-terry-tao-became-an-evangelist-for-ai-in-math-20260608/.
First, shared exposure implies we’re using the same vendors (Palo Alto, AWS, Cloudflare, etc.). Second, distributed visibility because no one sees full traffic patterns across institutions. Third, network effects since we can build better models with shared telemetry. And fourth, adversarial reuse appears as attackers probe borders across institutions in repeatable ways.
Opposing a firewall under the flag of academic freedom is indeed to use a false flag. The more fundamental issue is an endemic mistrust of institutional administration (“surely you’re using these tools to spy on us”). The irony that these same individuals fully embrace commercial tools with business models based on spying on their customers is lost on no one.
I searched for discussions of this issue - there are many - for example https://edtechmagazine.com/higher/article/2026/03/cloud-security-monitoring-higher-education-minding-visibility-gap-perfcon. But notice who’s quoted, major vendors selling point solutions, not higher education practitioners.
Yes, I realize that this bundling, when done well, can make managing these services less burdensome.
As I’m copy editing this, it struck me that this might be the most interesting question raised in the entire post. I’ll have to return to it in the future.
I think of the fine work done by the Trust and Identity folks and NetPlus team at Internet2 as solid examples of community driven collaboration. The work done on Science DMZs also jumps to mind, as does some large scale collaborative infrastructure projects like the Open Science Grid.
I am increasingly convinced that many of the issues we believe are truly local (e.g., governance, policy) are in fact as amenable to large scale collaboration as are purely technical challenges. It would make a terrific study to see if even something as idiosyncratic as risk tolerance really occupies a broad spectrum, or if our love of marveling at a problem merely makes it seem that way.