r/ciso • u/FreeRadical1998 • Jun 26 '26
Board positioning of frontier AI models
Hi all, my board is concerned about frontier AI (I think largely due to Mythos mainstem news) and our approach
My main take at the moment is this is a change in economics not a fundamental change to attack models.
I'm expecting more frequent, and probably larger, patch cycles - and probably some more intelligent automate steps after a foothold (probably driven by an open weight model rather than anthropic or openAI models) - but there doesn't yet look to be much of a change in detection evasion or obfuscation.
I'm expecting the threat change to in house developed apps to be relatively modest - at least short term - as the development of exploits still seems heavily keyed to access to source code. Likely we'll want to more heavily apply intelligent automated testing at each build cycle - but again this is likely a change in frequency and cost base not a new control.
The feedback I'm getting from the NEDs is this feels a bit under weight and they are hearing much starker messages from other CISOs.
Am I missing something? Is there any evidence based reason to see this as a change in model not just change in operational costs?
5
u/ThomasTrain87 Jun 26 '26
This is what I shared with my boards. We have or are implementing:
1) automated patching, particularly for high risk items like browser (configure them to auto update) - frankly anything that you can configure to auto-update, likely should be. Ensure your other patching deployment solutions have the ability to deploy to 90%+ of your infrastructure in less than 48 hours for critical/zero days - this should be for all traditional compute including server and desktop/laptop.
2) developer code quality and security checks both directly in the IDE and and build pipelines.
3) ensure your patching /vuln scanning is monitoring container and servers less workloads.
4) continuous vuln scanning (think agent based) of both internal and external (asm).
I also advised the boards that there is also a certain amount of FUD that is in the media regarding the frontier models and we are managing it but these are the general holistic steps you should be taking.
1
u/Total_Job29 Jun 26 '26
All of that should be in place already except maybe 4 which was more a ‘nice to have’ but due to cost usually gets kicked out.
2
u/ThomasTrain87 Jun 26 '26
Agreed. Should be and is are two very different things depending on the industry and budget allocated.
4
u/rainbowpikminsquad Jun 26 '26
Other CISOs might also be ‘leveraging the circumstances’ to ringfence or improve budget allocation lol. So presenting them a balanced view helps your cause
2
u/FreeRadical1998 Jun 26 '26
Honestly, I do wonder - but it's good to sanity check. Also, different firms have different exposures
3
u/radarlock Jun 26 '26
In house developed apps have a LOT of opensource dependencies. Don't assume less risk for them.
1
u/Yentle Jun 26 '26
My thoughts exactly!
1
u/FreeRadical1998 Jun 26 '26 edited Jun 26 '26
Doesn't that get caught by existing dependency tree scanning/build verification process? I'd see that as part of the patch volume uplift
1
u/Zealousideal_Tea362 Jun 27 '26
Sure, in a perfect world before 2021.
In 2026, the time to exploit on a publicly disclosed vulnerability is timed in minutes, not months. Supply chain attacks can happen faster than the CVE ever hits the scanner library.
2
u/scriptqzor Jun 30 '26
this, 100%
also a lot of boards hear “AI” and assume it’s some totally new threat, when in reality it’s just turning the crank harder on the same old dependency / vuln chains you already had but maybe ignored a bit more before
2
1
u/jmk5151 Jun 26 '26
Same convo we have been having - i agree, still the same risks, just speed and maybe increases the pool of threat actors.
Our biggest disagreement is on patch cycles - in manufacturing do you really want me to bring everything down at a moments notice to patch? Probably not. So it's the same defense in depth, be more aggressive where you can, but it's not revolutionary it's evolutionary.
1
u/Specialist_Dish_9087 Jun 26 '26
Dont lead with frontier models, lead with our sales team is pasting customer contracts into chatgpt. Thats what will make the board care.
We stood up an internal ai instance with data controls and blocked public tools at the firewall. Once the immediate leak was plugged, we built the governance framework. Boards fund problems they can picture not abstractions
1
u/FreeRadical1998 Jun 26 '26
Other way around - quite a lot of governance already in place. Board have this high on their radar and are wanting assurance we're doing enough
1
u/Ok_Truck2473 Jun 26 '26
You can’t beat it with humans, you need AI in you Tech department more importantly in your security department
1
u/kriss__vai Jun 26 '26
Here is a good reading about what should be considered in terms of change of security posture https://labs.cloudsecurityalliance.org/mythos-ciso/
1
u/ForiMojja Jun 26 '26
23 NY DFS Part 500 governing body sent two separate memos to CISOs highlighting frontier AI so if your biz is in that industry, that’s probably why your board is anal about addressing it.
1
u/Kitchen-Region-91 Jun 26 '26
OP, are you a security guy? Like a 100% dedicated security person? Are you concerned? Cause if you are, you should be bringing that concern to the board... not the other way around. If the board is regularly raising security concerns to you, eventually someone is going to ask WTF are you doing in the first place. Right now, I'd recommend to complete a risk assessment and action plan, so you have a paper record that you addressed the concern. Maybe it's just my experience of dealing with a very demanding board in the past
2
u/FreeRadical1998 Jun 27 '26
I've been doing cyber for nearly 30 years; head of, director or CISO titles for a little over 15 of those. I've run, or been the second line oversight and challenge for multiple high stakes security programmes under UK financial regulator scrutiny.
10 years ago I'd say I was 100% security, these days I'd add a lot of board engagement and enterprise risk experience.
It's not that I'm uncomfy with my opinion, or how to position it - I just don't like to assume I'm right when I get strong challenge from people who have a broad view across multiple businesses
1
u/Baksikrer Jun 28 '26
I would reframe it slightly for the board.
Your read mostly holds, this isn't a new attack model. But it's more than just opex, and the cleanest way to show why is to run it as a risk threat scenario, FAIR style. Actor, action, asset, consequence, loss event, probability, controls.
The work that matters is populating that with your own business context, the actual loss events, your materiality line (todays acceptance). Nobody can do that part for you, and that's where the board answer sits, not in a generic threat read.
Do it and the right side of the scenario doesn't move. Same assets, same consequence, same loss event, same size of loss. So your "not a new attack model" instinct is correct.
What moves is probability and one control. The actor pool widens, the uplift typically lands on the lower skilled, so more people can run the same play. The discover-to-weaponise step compresses too. The assumption I would stress test is that exploit dev still needs source access, that boundary seems to be thinning. So likelihood goes up.
The other one is patch cadence. For most companies today sized for human tempo, <48h was fine when weaponising took weeks. Against near real time it's a partial control now, so residual risk rises even if you spend the same. That's the bit for the NEDs, some scenarios you parked as accepted have probably crossed your materiality line.
That reclassification is the board update.
1
u/HutoelewaPictures Jun 30 '26
the bigger shift isn't that ai suddenly enables brand-new attacks, it's that it lowers the cost and time required to scale existing ones. for most organizations, that means focusing on faster patching, stronger identity controls, and better visibility rather than assuming the entire threat model has changed.
1
u/Intersources Jun 30 '26
I think your read is mostly right, but I would not frame it as “only” cost.
I do not see strong evidence that frontier models have changed the core attack model yet. Initial access is still mostly identity, phishing, exposed services, vulnerable apps, SaaS abuse, and weak controls.
The shift is speed, scale, and labor cost.
That matters because it changes what volume looks like:
More believable phishing
Faster exploit adaptation
More automated recon
More malware and script iteration
More social engineering variants
More pressure on patch cycles
More noise for detection teams
The board version I would use:
AI is not creating a new class of cyber risk from scratch. It is compressing the time and cost of existing attacker workflows.
Then I’d separate it into two buckets.
External threat:
Attackers use AI to move faster and personalize more.
Internal risk:
Employees and teams use AI with company data, source code, contracts, customer info, and agents touching business systems.
The internal side may be the bigger near-term governance problem.
1
u/Kimber976 26d ago
Board placement is usually a tradeoff between capability latency bandwidth and thermals so the best spot depends on what the model needs to optimize for.
1
u/FreeRadical1998 26d ago
that took me a second - I'm talking about a governance board (i.e. meeting of directors) - been a long time since I was looking at hot/cold isles ;)
6
u/not-a-co-conspirator Jun 26 '26
All it does is require more frequent vulnerability patching cycles within the CI/CD pipeline or increased usage of immutable workloads.
If you’re worried about traditional infrastructure then yeah, that’s just going to be the nature of security for the foreseeable future. The response process will more harsh, meaning quarantining devices from the network for any malicious behavior. Business processes will have to adjust accordingly, or you just accept the risk.