Once upon a time I took a ride in a car share service (not naming it) in Los Angeles. I got a 'shared' ride, which was cheaper, seemed like it would get me where I needed to be on time, and thus was my best option. Surely, thought I, the All-Powerful car share service's (not naming it) AI would know we were all going to same direction etc. First the car picked me up. Then it drove over to another location to pick up the next rider. Then another. Then, after riding around LA (I'm not from LA so we might as well have been driving around the desert) we dropped off one rider, the one who got in last. Then we dropped off the first other rider. Then we drove around some more. Finally we got to my destination. I looked at the driver. He looked at me. For the first time we spoke to each other. I said, "How could I do better tomorrow?" He said, "You need to start sooner." I thanked him, gave him a five-star rating and a nice tip because he had given me the be...

Let's talk about team dynamics, both in general and then specifically what Pythia Cyber can do to help you improve or maintain your cybersecurity team's performance. We start with that tired cliche, the crew team. On the surface, what a metaphor! You are all literally strapped into the same structure and all doing basically the same thing. It seems as though it would be easy to see if everyone is doing their job. Teamwork makes the dream work! Furthermore the usual thing is to picture a great crew having a great row. This image is, to say the least, skipping over an awful lot of reality. I know because I rowed a little myself and was the worst part of a great team and the mediocre middle of a terrible team. Those experiences were very different from each other, although superficially similar. In high school I was asked to fill for an absent team member for a coxed 4. I found the experience delightful, except for the extraordinary amount of effort and fatigue. We hummed along qu...

The technological base of most modern networking is rather naive with respect to security. It was created on the assumption that connection was good and that networks exist to transmit data and facilitate access to resources. Ah, the innocence of those simpler times. The same was true of most software: it was written to be used. Once you logged into the mainframe or minicomputer or departmental server, you were authorized to do whatever there was to do. The original PC environments had no authorization at all: you turned them on and started typing. This history means that an awful lot of technology's original authorization scheme was "none at all."  Adding authorization has not been easy, especially in a client/server environment. In a client/server environment we rarely can be certain of the other end which makes trust difficult to establish and maintain. Early authentication was based mostly on permission schemes layered on after logging in. Early sys admins used permis...

I want to expand slightly on a recent post of Ted's entitled We Said/He Said: Protecting The Wrong Things . That post takes a high level look at the problem of protecting the wrong things in your cybersecurity program. This post takes low level, nuts-and-bolts look at the same problem. I know from personal experience that there is a lack of continuity between the C-Suite and the lower echelons. By personal experience I don't mean decades ago, when I was a humble computer programmer; I mean yesterday because I am still a (part-time) humble programmer. At every stage of my career I have continued to be a technical contributor at the same time I was advancing. This started out as a temporary issue caused by a career transition but this duality is so useful that I made it a feature of my career. (This isn't as odd as it might sound: our local ambulance company requires its senior staff to ride the vehicle one weekend per month and our local hospital requires their senior staff ...

I want to recommend this article to my fellow cybersecurity professionals: https://thehackernews.com/2026/07/thinking-fast-and-slow-in-soc-case-for.html It does a nice job laying out reasonable roles for AI (pattern-matching donkey work) and human co-pilots (distinguishing the abnormal from the malevolent). Since a big part of why Pythia Cyber exists is to get more people in management to see cybersecurity as part of their job, I am going to write the rest of this post as a way to explain this strategy by way of an analogy that is not based in cybersecurity. Once upon a time I consulted to the laboratory medicine department of a large academic medical center. A large clinical laboratory is not a monolith, it is a conglomeration of different focus areas such as Immunology, Hematology, Chemistry, Virology and some other more obscure areas. The goal was to interface automated analyzers to the Laboratory Information System (LIS), but not directly because it was common wisdom that a qualifi...

Ross Young came out this weekend with (another) excellent essay. It aligns completely with what we say here at Pythia Cyber. The topic is aligning what your cybersecurity team protects with what the business needs protecting. I'm pasting in Ross' main slide as it's excellent. These are what different stakeholders want in terms of "protection." Note that first what they want differs maybe from what you think they want. Second, what it takes to protect what different stakeholders want protecting is different. Third, and this is critical you need to do all of this. We'll expect the tech leader to know how to protect different systems using different processes. The point from a behavioral science perspective is that tech leaders need the talent to get to know who wants what protected. It's not good enough to presume that you know better, or you have heard it before. Talented tech leaders deliberately create engagement with stakeholders to learn so that there...