Small, Boring Habits and the Art of Paying Attention

What a monk-turned-MIT-grad taught me about attention, energy, and happiness, and what the book of Proverbs taught me first.

I've become a regular listener of Sandeep Swadia, better known on YouTube as the MIT Monk. His videos feel genuine in a way much of the self-improvement world doesn't. He brings together science, strategy, spirituality, and his own hard-won story, and he never loses sight of what matters most to him: a real love for people and a desire to help them think differently about their lives. His latest video argues that the path to getting your life together runs through small, almost boring habits rather than bigger dreams or more motivation. What follows is my summary of his framework, my attempt to wrap my head around its three pillars, and the takeaways I'm claiming for myself.

Why this one hit close to home

I've had to learn attention the hard way. If I'm honest, for the first half of my life I was an average listener at best. I had read a lot of books, traveled widely, and collected more experiences and ideas than I knew what to do with. So in conversations, I heard people, but I didn't really listen. I was usually waiting for my turn, eager to share the next idea or story.

Leadership makes that habit easy to justify. The people you lead often want to hear from you. They want your direction, your vision, your answer. It's tempting to believe that speaking is the job. But the longer I lead, the more I'm learning that listening is the harder and more important skill, and like any skill, it needs practice. Listening well in the mundane moments, the exciting ones, the complex and complicated ones, and especially in the chaos, is an art.

And this isn't just a workplace problem. My wife would tell you it's a very real one at home. She has often told me, and not without reason, that I don't listen. I've come to see that some of this may be rooted in deeper things: our upbringing, the culture we come from, old wounds, and survival mechanisms we learned long ago that once protected us and now just get in the way. None of those are excuses. They are simply part of the honest work of understanding why I do what I do, so I can do better.

The book of Proverbs saw this long before any leadership book did. "If one gives an answer before he hears, it is his folly and shame" (Proverbs 18:13, ESV). That verse describes the younger me with uncomfortable accuracy. Elsewhere it warns, "When words are many, transgression is not lacking, but whoever restrains his lips is prudent" (Proverbs 10:19, ESV), and it observes that a fool takes no pleasure in understanding, only in airing his own opinions (Proverbs 18:2).

One tool that has helped me recently came from a course I took with Bruce Muzik called The Conflict Cure, and I'm sure similar tools exist with the same roots. It's called reflective listening, and it deserves its own post. The short version goes like this. First, mirror back what you heard, in your own words, to the person speaking. Then ask them whether you got it right, and whether there's more. Only when they feel fully heard do you move on to validating them, which means acknowledging that their perspective makes sense from where they stand, even if you don't agree. Finally, put yourself in their shoes and empathize with how they feel. It sounds simple. In practice, especially when emotions run high, it is anything but. More on that in a future post.

Ancient wisdom and a modern monk land in the same place: fewer words, more attention. Which is exactly why Sandeep's framework caught my attention, since his very first pillar is attention itself.

Don't look up

Sandeep opens with a story I haven't been able to shake. A friend of his who has summited Everest twice told him the secret to the final stretch: don't look up. Above 8,000 meters, in what climbers call the death zone, every step costs you, and staring at the summit can break you. So you keep your eyes down, take a step, pause, gather yourself, and decide on the next one.

Here's the thing: every big goal works that way. The book, the marathon, the business, the finances, the transformation project. From a distance, they all look like Everest. Small habits are what keep our brains from pretending we can climb the whole mountain in one go. Sandeep claims the right small habits don't just help you progress; they change the architecture of your life. He organizes nine of them under three pillars: attention, energy, and happiness.

Pillar 1: Attention

Correct after the click. An airplane on autopilot is almost never exactly on course. It flies as a series of small recoveries and still lands where it should. Most of us try to stop a bad reflex before it fires, and we fail because it's a reflex. Sandeep's approach: the moment you notice you've slipped (opened the app, reached for the ice cream), immediately attach one small good action, like standing up for a glass of water or a few deep breaths. He calls it interrupting the interruption.

Control your input. Psychologist Bluma Zeigarnik noticed that waiters remembered complex unpaid orders perfectly, then forgot them the moment the bill was settled. Unfinished things stay open in the background of your brain, draining resources like apps you forgot to close. His fix has two parts: batch your email and messages into two or three fixed windows a day, and touch each item only once using his 4D framework. Do it, delegate it, date it, or delete it.

Write to think. Amazon famously opened senior meetings with silent reading of a written memo rather than a slide deck, on the theory that slides can hide sloppy thinking while paragraphs force one idea to connect to the next. Research also suggests handwritten notes beat typed ones for conceptual understanding. Before a hard conversation or a foggy decision, write down three things: What do I know? What am I assuming? What is the next honest action?

Pillar 2: Energy

Quantize the action. Max Planck discovered that energy moves in small, discrete packets. Sandeep applies that to habits: shrink them to the smallest unit so starting takes almost no force. One line of writing. Half a push-up. A one-minute walk. The hardest part of any habit is the start, so make the start tiny.

Set a caffeine cutoff. Caffeine lingers for hours, and research shows it can disrupt deep sleep even when taken six hours before bed. You wake up groggy, reach for more coffee, and the loop feeds itself. The habit: stop caffeine at least six hours before bedtime, because protecting sleep may be the most productive thing you can do.

Ride the waves. Sleep researcher Nathaniel Kleitman found that our brains cycle through roughly 80- to 120-minute waves of high and low alertness all day long. The 3:30 p.m. crash isn't a discipline failure; it's biology. Work in a focused block of 60 to 90 minutes, then take a real recovery break of 10 to 20 minutes with no feeds, no inbox, and no new input. Then ride the next wave.

Pillar 3: Happiness

Look up. When life gets heavy, Sandeep steps outside at night and looks at the stars. Much of that light left its source long ago, and some of those stars may no longer exist. Whether you see it through faith or science, the mystery of our existence puts our troubles in perspective. The psalmist got there first: "When I look at your heavens, the work of your fingers, the moon and the stars, which you have set in place, what is man that you are mindful of him?" (Psalm 8:3–4, ESV).

Look in the mirror. The same elements that formed the stars formed you, and there is only one version of you: your story, your scars, your voice. Looking up reminds you you're surrounded by miracles. Looking in the mirror reminds you that you're one of them. I'd call that being "fearfully and wonderfully made" (Psalm 139:14).

Forgive yourself. Your habits will break. Your systems will break. In hard seasons, when every day is a firefight, none of these small habits will survive, and that's okay. You don't have to be your best self on your worst day. Self-prosecution drains you far more than a missed habit ever will.

My Takeaways

Here's where I landed, as a leader still learning to listen.

On attention, I'm applying "correct after the click" to conversations. When I catch myself jumping in with the next idea, I'm going to stop mid-reflex and ask a question instead. That's interrupting my own interruption. The 4D framework is going straight into my inbox routine, and "write to think" confirms something this blog has taught me for years: I often don't know what I think until I write it down.

On energy, quantizing is exactly how I need to approach the book I'm writing. Not "write a chapter." Write one paragraph. And I'm going to stop treating my afternoon dip as a character flaw and start scheduling around it.

On happiness, the three habits of awe, gratitude, and self-forgiveness sound soft, but I've come to believe they are what make every other habit sustainable. Grace isn't the opposite of discipline. It's what lets you get back up. "His mercies never come to an end; they are new every morning" (Lamentations 3:22–23, ESV).

The Takeaway

None of these habits are about pretending our problems are small. As Sandeep puts it, they're about remembering that our lives are large. Keep your eyes on the next step. Listen more than you speak. Protect your attention, your energy, and your joy. And when the habits break, and they will, forgive yourself and take the next step anyway.

Good habits won't keep you from ever getting lost. They'll help you find your way home.

Dr. Sam Kurien

The HAT Tool for a Leader Paying Attention

 The HAT Tool for a Leader Paying Attention

The most underrated leadership tool I know costs nothing, needs no license, and a strict Spanish nun modeled it for me decades ago.

When I was a young primary school student at a convent school, I avoided one person whenever I could: the principal. She was a Spanish nun, and she also taught me English, art, and physical education. She loved sports; she was strict, and her standards were impossibly high. Art was the subject I hated most. I did not like her, and I'm fairly sure she knew it. I can still hear her calling me "Samuel" whenever I was out of line or falling short of one of those impossible standards.

Years later, life came full circle. I went back to that same school to teach, and there she was. Same nun. Same standards, possibly higher. Only this time I wasn't at a desk in her classroom. I was working beside her.

And somewhere along the way, I came to love her.

Maya Angelou, the poet and Presidential Medal of Freedom recipient, is often credited with saying, "People will forget what you said, people will forget what you did, but people will never forget how you made them feel." I can't recall every lesson she taught me or every project we finished. But I have never forgotten how she made me feel: seen, believed in, and worth the effort.

She became my mentor, and far more than that. She gave me her friendship, the affection of a grandmother, her teaching, her prayers, and a steady push. The project I remember most is the school magazine. My desktop publishing skills were thin, and my writing wasn't much better. She didn't lower the bar. She stood beside me, gently pressing me to work harder, work smarter, and look again. Without my noticing, she was building something in me I didn't know was there: a sense of design.

That attention paid off. I still draw on what she planted, every time I design a system, a strategy, or a slide.

The idea that brought her back to mind

I recently came across a video and newsletter from a former monk, CEO who went on to MIT, and one line stuck with me: you can't be half-present and fully connected.

He wasn't talking about attention to detail in your work. He meant attention to the person in front of you. Anyone who has worked in technology knows what context switching does to a processor. It does the same thing to a conversation. Half our attention on the screen means half a connection with the human.

To practice this, he offers a simple framework he calls the HAT principle. In every interaction, offer at least one of three things.

H is for Help

Listen for what the person actually needs, not what you assume. Watch for what isn't said. My mentor never simply told me a magazine page was wrong. She sat down, showed me why, and told me what to try next. Her help met me where I really was.

A is for Appreciation

Be specific. I think of it as three levels, each going deeper than the last:

1. Say it: "Thanks, that looks great."
2. Name what they did: "Thanks, that looks great. Aligning the photos with the headlines makes the page easy to read."
3. Explain why it mattered: "…Parents will actually stop and read this instead of flipping past it. You have a real eye for this."

Level three is the one people carry for years. I know, because I still remember the times she told me something I'd done was good and why.

A few examples:

• To a staff member: "Thanks for catching that error in the budget report before it went to the board. You saved us a lot of headaches and protected our credibility. I really value how carefully you check your work."
• To a team: "You all stayed late to get the system back online Friday night. Because of that, students could register on Monday without a single hiccup. That's what ownership looks like."
• To a peer: "Thanks for looping me in early on that vendor decision. It kept my team from building something we'd have had to throw away."
• To another leader: "The way you handled that tough conversation in the meeting kept everyone at the table. I learned something watching you do it."
• To your child: "You finished your homework before I even asked. That meant we had time to go to the park together. I'm proud of how responsible you're becoming."
• To your spouse: "Babe, you found that billing mistake on the insurance statement. That saved us a lot of money, and honestly, I'd never have caught it. Thank you for looking out for us."

T is for Time

Give someone a few minutes without competing with your screen. Close the laptop. Turn the phone face down. Ask the question you've been meaning to ask. My mentor was running an entire school, and she still made time for me, again and again. I didn't understand then what that cost her. As a leader today, I do.

Why this matters for leaders, and for everyone

People rarely remember the memo or the meeting agenda. They remember whether the person in charge actually saw them. A leader who helps with real needs, names good work specifically, and gives undivided time builds a kind of trust no title can buy. My mentor held the highest position in that school, but her real authority in my life came from her attention.

You don't need a leadership role for this to matter. The HAT is really a daily workout for emotional intelligence and empathy. Looking for ways to help trains you to read what others need. Specific appreciation trains you to see the good in people, not just the gaps. Giving time trains you to put someone ahead of your distractions. Practice it long enough and it stops being a technique. It becomes who you are.

And it's small. A sentence of encouragement. Five minutes without a phone. One practical offer of help. Small things, given consistently and generously, compound.

The Takeaway

Even when you feel overlooked yourself, and most of us have, you can still help someone else feel seen. Take care of yourself, but when you have a little attention to spare, spend it. You are holding something valuable.

A strict old nun did that for a young teacher who once couldn't stand her. It changed the course of my life.

So this week, put on the HAT. Pick one person and offer at least one of the three. You may never see how far it goes.

Dr. Sam Kurien

What is a Vector Database?

Vector Databases: Where They Actually Earn Their Keep

You can bolt a vector approach onto your relational database as you implement AI use cases in your organizational environments.

With a new database type showing up every few years, it has become common for half of any conference session on that new type to be spent redefining the term for a new audience. Right now vector databases are having their time in the sun, and everybody seems to need one for their RAG pilot or their AI-assisted service in the enterprise. Below the level of the slides and the conference talks, though, vector databases are not terribly complicated. An embedding model turns input data — text, images, support tickets — into a vector of numbers. Those vectors get stored. At query time, you embed the query the same way and search the stored vectors for the ones closest in meaning.

What it actually is

So first off, let me define it. A vector database is a database where you store vectors in a high-dimensional space — think 50, 100, 1,000 dimensions or more — and where you can query for the vectors most similar to a given vector in that space. There are broadly two strategies for getting data into that space: single-shot approaches, where an entire item is mapped to one vector, and chunking approaches, where the data is split into pieces and each piece is embedded separately.

In terms of suitability, vector databases fit retrieval problems where many items in a dataset are all somewhat like one given item. They are a poor fit for problems where you need to find the single row matching an exact set of criteria. That second category is what relational databases have always been good at. Postgres is very well suited to finding one specific piece of data given criteria that match on every field — think where user_id = 4471. That is in sharp contrast to what a vector database does, which is to hand you back the twenty items most similar to a given item.

Both kinds of system sit on top of storage engineered for a high volume of lookups, so in that sense they are cousins. The difference is in how the lookup happens. A relational database evaluates a set of criteria against the fields of each candidate row to determine a match. A vector database compares a query vector against the stored vectors — all of them, or more often a subset — using a distance metric, and returns the closest ones. Which metric you use depends on the nature of the data, but cosine similarity and Euclidean distance are the usual suspects.

Most vector databases use approximate nearest neighbor (ANN) indexes, such as HNSW or IVF, to make the search efficient. The primary trade-off with these indexes is precision against performance: the index may return vectors that are slightly less similar than the true nearest neighbors in exchange for returning them much faster. At very large scale — hundreds of millions or billions of vectors — even a small amount of additional retrieval time makes a real difference, so giving up a little accuracy is often an acceptable price for a real-time interactive application.

Where the engineering complexity actually lives

I think the biggest misperception about the engineering required for vector databases is that the hard part is the storage. It isn't. It's the indexing. There are a number of approaches, each with its own trade-offs, and a great deal of engineering goes into wringing performance out of them.

HNSW (Hierarchical Navigable Small World). Builds a multi-layer graph in which each vector is connected to its neighbors. A search starts in the coarse upper layers and descends into progressively finer ones. It is very fast and, for many applications, very accurate — which is why it is the default index in a lot of vector databases handling real-time interactive workloads.

IVF (Inverted File Index). Organizes all the vectors into partitions — buckets or clusters — centered on a set of centroids. At query time, you identify the clusters of interest and only traverse the vectors inside them. You give up some precision for a given recall target in exchange for speed. At very large scale (100M to 1B+ vectors), narrowing to a subset before running the similarity search is frequently the only remaining lever you have. IVF variants differ in how they structure partitions and how they select centroids, which is what lets the approach cover a lot of different use cases.

Product quantization. Compresses the stored vectors to reduce memory footprint and to cut the number of operations needed for each distance computation. It is very often paired with IVF — IVF-PQ — as the retrieval strategy for huge datasets.

Flat, brute-force scan. The simplest method of all: no index, just compare against everything. Worth remembering that brute force is exact — it never returns a wrong answer; it just gets slow. That makes it the right call more often than people assume, for small collections or anywhere exact results genuinely matter more than latency.

None of these is better than the others in any absolute sense. Each represents an engineering trade-off between latency, recall, and memory for a specific use case. Saying HNSW is the best index for every problem is about as sound as saying every workload belongs on the fastest disk tier.

Where retrieval quality actually comes from

Here's the core of the problem, and I'll defend it: the index is not what's failing your RAG system. The chunking and embedding strategy is.

The quality of the index depends entirely on the quality of what went into it — chunks of a document, embedded into a vector space by an embedding model. At retrieval time, the same model has to embed the query so the two can be compared. If the model that indexed the corpus and the model that embeds the queries are not the same model, you are comparing coordinates from two different spaces that happen to have the same number of dimensions. The similarity scores that come back will look perfectly reasonable and mean absolutely nothing. Swapping embedding models mid-project causes a great deal of pain for exactly this reason.

Two things I've seen bite teams repeatedly:

• Naive token splitting underperforms semantic splitting. Cutting every N tokens regardless of structure produces chunks that straddle two unrelated ideas. Split on paragraphs, headings, or logical sections instead.
• Embed consistently. Use the same model for your corpus and your queries. Embedding models are defined in terms of a coordinate space, and two models with the same dimensionality are not defined in the same coordinate space. Swapping one for the other is switching to an entirely different space, and retrieval breaks completely — silently.

It is also very useful to store metadata alongside the vectors: source, date, tags, owner, department. That metadata is what lets you filter candidates out before the similarity search runs, or filter results after it returns. A lot of teams realize too late that retrieval is the part that matters, and that a nice demo can hide an enormous number of problems.

Security, or why retrieval carries a false sense of safety

This is the part of the architecture everybody wants to skip, because storing derived numbers feels safer than storing sensitive text. It isn't. As I alluded to above, it is often possible to reconstruct or infer meaningful information about the original input from the embedding itself, particularly when the model is known.

So treat the vector store with the same rigor you would apply to any production database holding regulated data. That means access controls, tenant isolation, encryption at rest and in transit, and deliberate logging discipline around both query vectors and retrieved results — the queries themselves are a sensitive signal, not just the documents. Enforce metadata filtering before retrieval rather than bolting it on afterward. And in a regulated environment, keeping the whole retrieval layer inside your own VPC is usually the difference between a straightforward compliance conversation and a painful one.

Where this shows up in practice

The dominant use case at the moment is supporting a generation model: embed a large corpus, store the vectors, retrieve the relevant chunks for each query, and pass them to the model as additional context. But it doesn't stop at semantic search — the same mechanics power recommendation, anomaly detection, and deduplication. Here is how this tends to land in three domains I get asked about often enough to be worth spelling out.

Higher education. For a university's AI advising assistant to be useful to students and staff, it has to retrieve across financial aid policy, degree requirements, and course catalogs from every department. Financial aid policy changes year over year and by cohort, and it varies with in-state or out-of-state status, scholarships, and professional programs. So chunk that content by policy section and effective date rather than by PDF page break, or you will confidently serve a 2019 refund policy in answer to a 2026 question. The access control point from the previous section is not theoretical here either: a student must not have a path, even an indirect one, to another student’s advising notes or FERPA-protected records simply because their embeddings landed near each other in the vector space. Filtering by student ID and role before the similarity search runs is what keeps this a retrieval system rather than an incident report.

Finance. Research desks and trading floors accumulate documents continuously — vendor research, internal risk memos, filings — over long periods, with vendors added and dropped along the way. Two failure modes show up here reliably. The first is the model swap: a collection is built with one embedding model, someone later substitutes a comparable one, and answer quality quietly collapses while the similarity scores continue to look flawless. The second is staleness. Without collection-level metadata — when a document entered the corpus, how many revisions it has been through, whether it has been superseded — an analyst will eventually get handed a three-year-old note with no indication that it no longer reflects the house view. Filtering on that metadata before retrieval is the fix. And logging discipline matters twice over in this domain, because query vectors over trading strategy documents and client portfolio data are themselves sensitive.

Healthcare. Consider semantic search over clinical notes and discharge summaries for a clinician-facing assistant. Clinical narrative is exactly the kind of narrow, structured, sensitive text where reconstruction risk against embeddings is highest, so PHI-bearing vectors belong behind the same authentication and audit controls as the EHR itself — not a lighter-weight index sitting alongside it. On the retrieval side, chunking by clinical encounter and tagging each note with department and note type (history and physical, progress note, consult) is what keeps a nurse's query about a medication history from surfacing that patient's psychiatric notes. That is as much a chunking and metadata design decision as it is a policy one.

The Takeaway

A vector database is more than a search index bolted on top of your stack. It is part of your data layer, and it deserves the same rigor you would give any production system holding data your organization is accountable for. The indexing algorithm is the interesting part, but the chunking strategy is the part that decides whether retrieval is any good, and the access controls on the retrieval layer matter every bit as much as the ones on the rest of your data layer. Get the interesting part right and skip the other two, and you will have built something fast, confident, and wrong.

Dr. Sam Kurien

The Quietest Thing an Attacker Does After Root

Privilege escalation gets all the attention. It's the dramatic beat in every write-up — the moment the shell prompt flips from $ to # and the attacker owns the box. But in my experience, escalation is rarely the point. It's the ticket. What the attacker does with that ticket in the next ninety seconds tells you far more about their intent, and it's usually the thing that leaves the evidence you'll actually use later.

So let me pick the one action I find most instructive to reason about: installing a persistence mechanism. Specifically, a malicious systemd service on Linux. It's unglamorous, it's common, and — this is the part I want to sit with — it's a control the defender can win, if they understand what they're really watching.

What the attacker gains

The honest answer is time. Everything else follows from that.

An exploit is fragile. It depends on a vulnerable version, a reachable service, a particular condition holding true. Patch the service and the door closes. This is exactly what I saw in this week's lab work chaining CVE-2025-32433 — the exploit is a beautiful thing until the target gets updated, and then it's a museum piece. An attacker who has done any real work to get to root is not going to leave their continued access hostage to a CVE that could be remediated on Tuesday.

Persistence decouples access from the vulnerability. A systemd service that calls back on a schedule survives reboots, survives the patch, and survives the analyst who thinks closing the original hole ended the incident. That last one matters more than people admit. I have watched remediation efforts declare victory on the entry vector while the persistence quietly sat one directory over, waiting. The attacker's goal isn't a shell today; it's a shell next month, on their terms, after everyone has stopped looking.

Systemd in particular is an attractive home because it's legitimate infrastructure. A rogue .service unit dropped into /etc/systemd/system/ with an innocuous name blends into a directory full of things administrators are conditioned to trust. Enable it with systemctl enable, and the OS itself becomes the thing that maintains the attacker's foothold. That's the uncomfortable elegance of it — you're not fighting malware anymore, you're fighting the service manager doing its job.

What it leaves behind

Here's my core claim, and I'll defend it: persistence is loud if you know where to listen, and the attacker's need for reliability is what makes it loud.

Reliability requires artifacts. A callback that has to survive a reboot must be registered somewhere durable. That durability is the tell. You cannot have persistence that is both reboot-surviving and evidence-free, because the mechanism that survives the reboot is, by definition, written down somewhere the system reads on boot.

For a malicious systemd service, that "somewhere" is a short list:

• A new or modified unit file, typically under /etc/systemd/system/ or /usr/lib/systemd/system/, with a creation or modification timestamp that rarely matches any change window you can account for.
• The payload itself — an executable or script, often parked in a world-writable path like /tmp, /var/tmp, or /dev/shm, or masquerading in /usr/local/bin.
• Journald entries showing the unit being enabled and started, which is the service manager narrating the attacker's actions in its own logs.
• The behavioral signature at runtime: a process spawned by systemd (PID 1 lineage) that promptly opens an outbound socket to a host that has no business being contacted from that server.

None of these is subtle once you've decided to look. The problem is almost never that the evidence is absent. The problem is that nobody correlated the file with the process with the connection.

How a defender detects and investigates

If I could give a defender one piece of advice here, it would be this: stop watching for "a bad file" and start watching for "a change to how this host schedules and runs code." That reframe is what makes the detection durable against an attacker who has read the same hardening guides you have.

Concretely, in order of what I'd reach for first:

File integrity monitoring on the systemd unit directories is table stakes, but on its own it only tells you a file appeared. Pair it with auditd rules that watch those same directories and record execve calls, so you catch not just the unit file being written but the payload actually running. FIM tells you the trap was set; auditd tells you it sprang.

Then correlate on lineage and behavior. A process whose parent traces back to systemd, launched from/tmp, opening an outbound connection, is a specific and huntable pattern. I care much more about that causal chain — scheduler spawns unusual binary, binary calls home — than about any single indicator in isolation. It's the combination that turns a maybe into a finding without waiting on reverse engineering.

For the investigation itself, the questions I'd want answered are the boring, useful ones. When was the unit file created, and by which subject’s session? Correlate that timestamp back to the authentication and process records around it — the same logon-session pivot I'd use for account-creation cases applies here. Has the service fired more than once? Journald and execve records give you every invocation, which bounds how long the persistence has actually been live and therefore how far back your scope has to reach. And critically: does the entry vector's remediation actually touch this? If not, you haven't closed the incident. You've closed a door in a house with an open window.

The takeaway

Privilege escalation is the headline, but persistence is where the investigation is usually won or lost. The attacker installs it because they need reliability, and that same need for reliability forces them to write something durable to disk and register it with the system — which is precisely the evidence a prepared defender is watching for. The mechanism that keeps them in is the mechanism that gives them away.

Watch the scheduler, not just the file. Correlate the artifact to the execution to the connection. And never let anyone declare an incident closed on the strength of a patch alone.

Privilege, Not Passwords: Where the Real Risk Lives

I wrote this for a class post and thought it was worth capturing here as well, both to share and for my own future documentation of where I landed on this.

I've been following a debate that keeps resurfacing — in our own classroom, in vendor briefings, and in boardrooms alike: which is the bigger security problem, weak passwords or weak privilege management? Most people settle firmly into one of two camps. Having spent more than one season of my career building and contributing to an identity management product, I'd like to try bridging the gap — though I'll confess up front that I've already picked a side. Privilege is the bigger governance and management problem, and it deserves the stronger focus. Let me explain.

Password vulnerability is a real problem, but the initial breach of an organization's systems through a login is, at this point, close to inevitable. Most large breaches begin with adversary-in-the-middle (AitM) phishing that bypasses MFA, or with infostealer malware quietly harvesting credentials by the thousands. And service accounts, by their nature, cannot use MFA at all. So under an assume-breach mindset, the decisive question is not whether an account will be compromised, but what that account can then access. A typical user account can be contained as an incident. An over-privileged identity is something else entirely: an attacker can escalate from it, disable security tooling, move laterally across the network, and establish the command-and-control foothold that turns a phishing click into a ransomware event. The privilege granted to the initially compromised identity determines the blast radius of the incident.

Meanwhile, the password problem is slowly solving itself, for the most part. NIST's recently finalized SP 800-63B-4 (National Institute of Standards and Technology [NIST], 2025) decisively shifts password guidance toward length, breached-credential screening, and phishing-resistant authentication. I've written before about my enthusiasm for moving toward passwordless login using passkeys and methods such as FIDO2 — eliminating the shared secret that attackers phish, spray, and stuff. But notice what a passwordless world leaves behind. Entitlements will still pile up on individual accounts. Accounts belonging to former employees will still be abandoned rather than deprovisioned. Admin rights needed for a two-week project will still be found, years later, quietly attached to someone's identity. A password policy, once set correctly, largely holds its value. A privilege model erodes daily unless it is actively managed and governed.

That is why I consider identity management and zero trust not to be two separate security solutions, but two components of a complete, layered defense. Zscaler seems to have solved a good deal of this (I have nothing to do with Zscaler, and I am not promoting them here). In a zero trust architecture, no user, device, or network location is implicitly trusted, and every request must be verified (Rose et al., 2020) — meaning that when another control fails, identity is the layer that bears the brunt of the damage. In practice, I am a strong believer in combining Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). RBAC is the right starting point: map users to the roles their jobs actually require, and audit regularly to ensure every entitlement is accounted for. But roles are static by nature. ABAC adds the dynamic layer — factoring in the posture of the user's device, the location they're connecting from, and the classification of the data they're trying to reach. Combined, the two produce an access model that is both auditable and adaptive: what a user can access changes with circumstances, rather than sitting as a standing entitlement waiting to be abused.

One note I feel strongly about: the road to passwordless runs through strong passwords. Until the transition is complete, the credentials we still depend on must be hardened — going passwordless doesn't excuse weak passwords in the meantime; it depends on surviving the meantime.

A stolen credential gets an intruder into the lobby. Unmanaged privilege is what escorts that identity down to the server room or the boardroom, where everything that matters is kept. So harden the entrance — then govern everything beyond it.

References

National Institute of Standards and Technology. (2025). Digital identity guidelines: Authentication and authenticator management (Special Publication 800-63B-4). https://doi.org/10.6028/NIST.SP.800-63B-4

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero trust architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207

Your University's AI Strategy Shouldn't Look Like Anyone Else's

 I've been deep in the architecture of my next book — an AI playbook for higher education — and I keep bumping into a problem that most of the "AI will transform the university" content quietly ignores: which university?

Because here's the thing nobody at the conference keynote wants to say out loud. A flagship R1 with a medical school, a regional state comprehensive, a 900-student faith-based college, and a system office are not four sizes of the same institution. They're four different organisms wearing the same word, "university," and handing them the same AI strategy is like handing a powerlifter, a marathoner, and a guy recovering from knee surgery the same workout plan. Technically, it's all exercise.

So one of the chapters I'm building is devoted entirely to this, and the more I work on it, the more I think it's the load-bearing wall of the whole book. The premise: institutional type isn't a demographic footnote. It determines your core AI problem — the thing that will actually eat you if you ignore it.

At an R1, the core problem is coordination. AI is already everywhere on that campus — the engineering college has three pilots, the med school signed something nobody in central IT has seen, and forty faculty have quietly wired models into their research workflows. The flagship doesn't need an AI adoption strategy; it needs an AI governance strategy, and a federated one at that, because the colleges of medicine, engineering, and law will run their own portfolios no matter what the provost's council decides. Central's real job is setting the floor — data protection, disclosure, human decision rights — and auditing against it. Not approving projects. That ship sailed before the committee formed.

At a regional comprehensive, the problem flips. It's capacity. These are the institutions that need AI's efficiency gains the most — advising caseloads north of 300:1, a financial aid office running on caffeine and heroics — and they have the least staff to implement anything. The cruel joke of this moment is that the institutions with the strongest per-dollar case for AI are the ones least equipped to deploy it. (This, incidentally, is the thesis of the whole book: higher ed needs AI most at exactly the moment it's least ready for it.)

At a small private, the problem is readiness. The data spine — the SIS, the CRM, the warehouse — is often held together with spreadsheets and institutional memory named Deborah. The upside is that a small private's cabinet can move in one board cycle, no faculty senate marathon required. The downside is identical: it can err in one board cycle. Speed without a data foundation just gets you to the wrong place faster.

And at a system office, the problem is authority: what gets decided centrally, what stays on campus, and who pays. Anyone who's watched a system-wide ERP project knows this fight. AI just runs it at higher velocity.

Two wrinkles from the research so far that deserve their own paragraphs, because almost nobody in the sector is talking about them.

First: if you're a public institution, your AI policy isn't entirely yours to write. A growing number of states have issued executive orders or legislation governing AI use in public agencies, and public universities are frequently in scope. Your regional comprehensive may already have obligations flowing downhill from the governor's office that your cabinet has never read.

Second, and this is the one that made me sit back from the keyboard: sunshine laws reach algorithms. A public university's AI-influenced admissions or financial aid decisions are potentially discoverable — public records requests, litigation — in ways a private institution's never will be. If a model is nudging who gets admitted or how aid is packaged at a state school, assume that someday a reporter or a plaintiff's attorney will get to look under the hood. That should change how you write vendor contracts and how you build audit trails, starting now, not after the request lands.

The chapter ends with a diagnostic — place your institution on the grid, then every subsequent chapter of the book closes with a "how this plays for you" note keyed to your archetype. Because a playbook that pretends the whole sector runs the same offense isn't a playbook. It's a poster.

More as the book develops. If you lead technology at one of these four kinds of institutions and your AI reality doesn't match my grid, I genuinely want to hear about it — the grid gets better when it gets argued with.  I think it would be a good idea to run a summary of all my chapters here and get genuine discussion going to reflect on and validate my ideas. 

Dr. Sam Kurien

DarkSword and Zero Trust Reckoning

 Threat Intelligence & Mobile Security

DarkSword and the Zero Trust Reckoning

The Collapse of iOS Inviolability — and Why Software Hygiene Is Now a Survival Metric for Institutions

For the better part of a decade, the default posture of any IT leader recommending a mobile device strategy was predictable: hand the executive an iPhone and call it a day. The logic was almost bulletproof. Apple's vertically integrated stack — hardware, OS, and App Store gatekeeping — gave the walled garden metaphor genuine teeth. While Android's fragmented patch ecosystem left enterprise security teams running perpetual triage, iOS was the closer-to-settled question.

I've used that framing in vendor conversations. I've built a mobile policy around it. And now, with the emergence of DarkSword, I find myself revisiting every assumption underneath it.

This is not alarmism. This is what the intelligence looks like from the ground — and what it demands of leaders who sit at the intersection of institutional trust and operational technology.

⚠ Threat Classification

DarkSword is a sophisticated zero-click exploitation framework documented by Google's Threat Analysis Group (TAG), Lookout, and iVerify. It operates via watering-hole attacks — compromised legitimate-looking web properties — to achieve remote code execution (RCE) through the WebKit engine without any intentional user interaction. It does not require a malicious app download. It does not require clicking a phishing link. It requires only that a device browse to an infected site. [See TAG advisory and corresponding CVE disclosures for technical attribution]

---

The Architecture of Compromise

What distinguishes DarkSword from the commodity malware cluttering most threat briefings is architectural intentionality. This toolkit was not built to linger. It was built for surgical, deniable exfiltration — a design philosophy more consistent with state-sponsored tradecraft than with the opportunistic criminal ecosystem.

The exploit chain targets WebKit — the rendering engine that powers every browser on iOS without exception, a direct consequence of Apple's platform policy requiring all third-party browsers to use WebKit. By exploiting a series of memory-corruption vulnerabilities in the WebKit JIT compiler, DarkSword achieves privileged code execution, escapes the application sandbox, and moves laterally into core system processes. From that position, the data exposure is comprehensive:

iCloud Authentication Tokens

Token capture enables access to cloud backups without triggering standard 2FA workflows. This is not a brute-force attack — it is a session hijack that appears to be a legitimate authenticated session from Apple's perspective.

End-to-End Encrypted Message Content

Encryption protects data in transit. DarkSword accesses data at the endpoint — after decryption — rendering transport-layer security architecturally irrelevant to this attack vector. iMessage, Signal, WhatsApp: the message content is readable at the device layer before any encryption is applied or after it is removed.

Keychain Access

For institutional users, this is the catastrophic tier. Corporate SSO credentials, VPN certificates, privileged access tokens, and — for any cryptocurrency-adjacent users — private keys. A compromised Keychain is a compromised identity, potentially enterprise-wide.

The initial geographic targeting — Saudi Arabia, Turkey, Malaysia, and Ukraine — is consistent with intelligence-service interest patterns. But that window has closed. The toolkit has surfaced on GitHub. We have entered what I would call the democratization phase of cyber-espionage: sophisticated zero-day weaponry, previously accessible only to nation-state actors with eight-figure operational budgets, is now available to script-tier threat actors and regional criminal cartels.

This is the threat multiplier that should concern every institutional technology leader. The original adversary was disciplined and selective. The downstream actors running forked GitHub deployments will not be.

---

The One-Fifth Vulnerability Gap

Apple has moved with unusual speed. Patches were issued in iOS 26.3 and the subsequent iOS 26.3.1(a), specifically addressing the WebKit JIT vulnerabilities in the exploit chain. Rapid Security Response (RSR) patches were also pushed for select configurations. From a vendor posture standpoint, Apple's response was close to the industry ceiling of what we can reasonably ask for.

~20%of the iOS install base is still running unpatched versions —
trailing iOS 18.4 through 18.7 — as of current estimates

That gap is not a technology failure. It is a human-systems failure — and, in an institutional context, a governance failure.

Consider what that 20% means in practice. Automated vulnerability scanners — the same category of tool that pen testers use — can identify unpatched WebKit targets at scale. A device running iOS 18.x does not need to be specifically targeted; it simply needs to be found. In a world of exploit automation, being three minor versions behind is not a risk posture — it is an open enrollment in the breach pipeline.

---

The Hardened Institutional Posture

The following is not a "best practices" checklist. It is the minimum viable defensive architecture for any leader responsible for sensitive institutional data — financial records, student information, executive communications, privileged credentials. The bar has moved. Adjust accordingly.

1

Eliminate the Update Lag — Immediately and Institutionally

The 48-to-72-hour window between patch release and device update is the primary operational window that exploit actors bank on. On the individual level, enable:

Settings → General → Software Update → Automatic Updates

Toggle both "iOS Updates" and "Security Responses & System Files" to ON. The latter enables Apple's Rapid Security Response mechanism, which pushes critical patches outside the standard update cycle.

On the institutional level: if your MDM (Jamf, Intune, Kandji) does not have an enforced OS version policy with an update compliance threshold, that gap needs to close in your next governance cycle — not next quarter. Define an acceptable lag window (72 hours for critical patches is a defensible standard) and enforce it through device enrollment policy.

2

Deploy Lockdown Mode for High-Risk Personnel and Environments

Standard iOS hardening is insufficient for DarkSword-class threats because the attack surface — WebKit JIT compilation — is not addressable through configuration alone. Apple's Lockdown Mode structurally disables the JIT compiler pathways and reduces the JavaScript attack surface upon which the exploit chain depends.

Settings → Privacy & Security → Lockdown Mode

Lockdown Mode carries real usability tradeoffs: certain web technologies are disabled, some file attachments won't open, and complex web apps degrade in performance. This is not a fleet-wide recommendation. It is the appropriate posture for executives, finance personnel, IT administrators, and anyone who regularly accesses privileged systems from mobile devices — particularly when traveling or connecting outside your perimeter controls.

3

Treat Mobile Browsing as a Hostile Environment

DarkSword's use of watering hole attacks — lookalike portals impersonating government contractor sites, enterprise SaaS login pages, and consumer tools like Snapchat — challenges the comfortable assumption that users can identify unsafe sites by appearance or reputation. DarkSword doesn't need you to download a file. It just needs you to view a page. That single fact should reframe how your entire organization thinks about mobile browsing.

The smishing vector deserves specific attention. A well-crafted SMS instructing a user to "verify your account" at what appears to be a legitimate government portal or enterprise login page is all DarkSword needs as a delivery mechanism. Train your users on one absolute rule: if a link arrives via SMS, social media DM, or personal email and it asks you to log into anything, do not click it. Type the address manually into the browser or navigate through a trusted password manager that provides domain verification.

On the institutional side, sensitive web navigation should happen through corporate-managed browser profiles with DNS filtering and Safe Browsing enforcement active. On mobile, this discipline is harder to enforce than on managed desktops, which is precisely why it must be a trained behavior and a user awareness priority — not an assumed one.

4

Treat Hardware Deprecation as a Security Policy Decision

This is the conversation institutional technology leaders consistently defer because it carries budget implications. DarkSword forces the issue. Devices that cannot run iOS 26 do not have access to the hardware-level exploit mitigations built into recent A-series silicon — specifically, Pointer Authentication Codes (PAC) and the memory-tagging improvements in more recent SoC generations that make modern exploits structurally harder to write.

To be concrete: an iPhone 8, iPhone X, or anything older cannot run the security architecture required to resist this class of exploit. These devices are not merely feature-limited — they are mathematically easier to exploit. The cryptographic and memory-isolation primitives simply aren't present in the hardware. An iPhone maxing out at iOS 15 or 16 is not a legacy device. It is a structurally undefendable endpoint.

If your organization has device refresh policies that allow five-plus-year-old mobile hardware to access institutional systems, that policy is now a liability exposure, not a cost-saving measure. Frame it that way in your next budget conversation.

5

Conduct an Emergency Institutional Audit — Today

This is the step most organizations skip, and the one with the most immediate risk-reduction value. Through your MDM console, pull a current OS version compliance report for every enrolled mobile device. Identify every device running iOS 18.x or earlier. Flag them. Communicate directly with those users. Do not wait for the next scheduled IT communication cycle.

If your mobile fleet is partially or entirely unmanaged — BYOD with no MDM enrollment — you need to initiate a more fundamental governance conversation. Start by quantifying the exposure you currently cannot see.

6

Monitor for Enclave Anomalies — Know the Behavioral Signatures

DarkSword is engineered to be stealthy — it does not announce itself with popup alerts or obvious system crashes. But even surgical exfiltration leaves traces. Active data transmission is power-intensive, and exfiltration operations that run while a device is idle create observable behavioral artifacts. Knowing what to look for is part of a mature defensive posture.

Train your security-aware users — and particularly your high-risk personnel — to treat the following as potential indicators of a compromised environment that warrant immediate device isolation and incident response:

• Unexplained battery drain or device overheating while idle. Background exfiltration consumes CPU and radio resources. A device that runs warm or drains noticeably faster when not in active use is worth investigating.
• Unsolicited prompts for iCloud password or Keychain access. A legitimate app or OS update will not ask for Keychain credentials out of context. An unexpected prompt — especially one that appears unprompted while browsing — should be treated as hostile.
• Unknown profiles in Settings → General → VPN & Device Management. This is the first place to look on any suspected device. A configuration profile installed without user knowledge is a reliable indicator of device compromise. Check this regularly on any device handling sensitive institutional data.

If any combination of the above appears, the correct response is not to dismiss it and monitor further — it is to remove the device from institutional network access, escalate to your security team, and treat it as a confirmed incident until forensic analysis says otherwise.

DarkSword is not a singular event to be patched and forgotten. It is a leading indicator of a structural shift in the mobile threat landscape — one that has been visible to security researchers for years and is now arriving as operational reality for institutional technology leaders.

The Zero Trust architecture principle — never trust, always verify, assume breach — was designed for exactly this threat profile. We have applied it reasonably well to network perimeters and identity management. We have applied it inadequately to mobile endpoints, largely because the "walled garden" narrative gave us permission to treat iOS as a trusted device by default.

That permission has been revoked.

Apple will continue writing patches. The adversary ecosystem will continue developing exploit chains. The variable that determines institutional outcomes in that arms race is not vendor response time — it is the culture of security discipline you build inside your organization. Update cycles enforced. Hardware policies rationalized. User behavior is shaped by training that reflects actual threat patterns rather than the last decade's phishing examples.

The 20% who aren't updating aren't negligent. They are people operating in an environment where security discipline has not been made structurally easy, institutionally expected, or consequently enforced. That is a leadership problem. Which means it is, for those of us in technology leadership roles, our problem to solve.

Don't be the institution that finds out, the hard way, that it was in the vulnerable 20%.

---

Quick-Reference: DarkSword Defense Checklist

• Enable Automatic Updates, including Security Responses & System Files
• Enable Lockdown Mode for executives, admins, and finance personnel
• Never click login links from SMS, DMs, or personal email — type URLs manually
• If on an iPhone 8, X, or older — plan an immediate hardware upgrade
• Pull MDM compliance report; flag and contact all iOS 18.x or earlier devices
• Audit Settings → General → VPN & Device Management for unknown profiles
• Report idle overheating, battery drain, or unexpected Keychain prompts to IT immediately

---

Source Note: The DarkSword threat intelligence referenced in this article is attributed to Google's Threat Analysis Group (TAG), Lookout, and iVerify. Readers in institutional security roles are encouraged to refer directly to the original CVE disclosures and TAG advisory documents for full technical attribution. As with all active threat intelligence, the landscape evolves rapidly — verify current patch status against Apple's official security release notes at support.apple.com/en-us/111900 or the equivalent current advisory page.