Jacob Collinson has been at Koltiv for six years. He is our cybersecurity consultant and vCISO, which covers both the engineering side and the consulting side: security posture, policies and procedures, backup plans, and disaster recovery planning for when something goes wrong.
Ask him to describe his job in one sentence, and he will tell you he is continuously working to improve his clients' security posture and always reviewing what already happened.
This wasn't the path he saw for himself when he was a kid. Law was the first plan, back when he liked to argue for its own sake. Engineering came next, since math had always been his subject, the one he could move through faster than everyone else and still get it right. He landed on IT in college through a roommate who was studying it, took a couple of intro courses, and found the material clicked immediately. He earned his master's in cybersecurity later at John Brown University, where his parents met.
Outside of work, he bowls in a Friday league with a former colleague and plays guitar, mostly acoustic with some bass. His playlists run to late nineties punk and rock, the kind of thing you can belt out in the car. Which leads to the one fun and surprising thing about him: Jacob can do heavy metal screaming vocals. He and his brothers could all do it growing up, so he assumed it was something anyone could pick up, and only later worked out that plenty of people who love that music cannot do it at all.
More fun facts about Jasob: He is a night owl, aiming for something close to midnight. Coffee, or occasionally a small Red Bull, is his caffeine of choice. And the show he has rewatched more than any other is Mr. Robot, which he admits is on theme, since it follows a hacker who spends time on both sides of the line.
That instinct for math never really left, though it shows up now as problem-solving. Jacob describes the work as looking at what you see first, then figuring out what is actually going on, because those two are not always the same.
We asked him what part of his job clients would find interesting if they could watch it happen. His answer was not a tool or a dashboard. It was what happens when a problem does not follow the usual path. Most issues have a known sequence. You work A, B, C, and you are done. The ones worth watching are the ones where the sequence runs out.
What takes over then is pattern recognition, built from years of seeing how these systems actually fail. Jacob will reach for something that does not look related to the problem on paper, and it turns out to be the thing, because he has seen the shape of it before, even when he could not tell you where.
"Sometimes things will just pop into your head to try that don't necessarily make sense. But it worked."
That is the part that never makes it into a ticket. As he puts it, it is knowledge you cannot really write down, and it is a large part of what you are actually getting when you bring in someone who has spent years doing this.
A recent one looked like this: A client's system administrator, someone who knows his environment well, was setting up a VPN connection for a vendor and ran into trouble. Jacob went through the configuration. Everything was set correctly, which is its own kind of dead end. He finally looked at the URL itself and recognized it as the company's old domain name, left over from before a change, which was why the certificate would not validate.
Nothing exotic, and no reflection on the admin. It is the kind of thing anyone stops seeing after looking at it long enough, which is exactly why a second set of eyes is worth having.
October is Cybersecurity Awareness Month, which means a lot of advice is about to come at you. We asked Jacob what is actually worth repeating.
His answer was network segmentation. A colleague who runs penetration tests recently walked him through a real test in detail, and Jacob's reaction was that pulling usernames and passwords off a flat network is easier than he had believed. Plenty of smaller operations still run servers, workstations, and everything else on a single network. If someone clicks the wrong thing and gets a foothold, that layout decides how far they get.
For ag and manufacturing, he wanted to name something more specific: your PLCs. Programmable logic controllers are the devices reading chemical levels, tracking how much grain is in a silo, and running your line. Disrupting a production line costs real money, so these are critical sensors. Some of them have been running fine for twenty years on an operating system nobody patches anymore, and replacing them is expensive enough that nobody is going to. That is exactly why they need to be segmented, with strict limits on what they are allowed to talk to.
There is an assumption Jacob runs into constantly: that attacks are aimed at large enterprises, and a mid-sized operation in Iowa is not worth anyone's trouble. His answer to that is short. "We've seen the gamut." Small clients, medium clients, large clients.
The reason is in how most attacks actually begin. They are not aimed at anyone in particular. Someone scans broad ranges of the internet looking for one specific exposure and takes whatever answers back. When a network gateway that let employees reach their desktops remotely turned out to be vulnerable, the companies that got hit were the ones who had left it open to the public, and their size had nothing to do with it. The same thing happened when a widely used firewall product had a serious vulnerability. If it was exposed, it was a candidate.
What has changed is the clock. The gap between a vulnerability becoming public and being actively exploited used to be measured in months. Then weeks. Jacob now puts it in hours. Sometimes the fix depends on a vendor releasing a patch, which means there is a stretch where reacting quickly is not available to you as a strategy.
That is the argument for what you have in place before anything happens.
None of which means you can get risk to zero. Jacob is direct that you cannot. What layered security buys you is size. He has watched the same initial mistake, someone clicking something, go two completely different directions depending on what was in place underneath. One turned into a full compromise. Another got caught by a second tool noticing the first machine reaching for things it had no business touching, which meant wiping two machines instead of rebuilding a network.
"It's about keeping it small, if and when it does happen."
Jacob spends most of his time on exactly this kind of question. If the segmentation piece made you wonder about your own network, or you are not sure what your PLCs can currently reach, that is worth a conversation before you need one.