Blog

Hurricane Season Is Here. Some Disasters Don't Give You Days.

Aaron Wickware, 8/4/2026

Every year around this time, the advisories start rolling in, the five-day cones show up on every local news broadcast, and businesses along the Gulf Coast start dusting off their disaster plans. That’s a good instinct. But it comes with a dangerous assumption baked in: that you’ll get days of warning before things go bad.

Sometimes you do. Sometimes you don’t.

Rapid intensification — a storm strengthening from a manageable system into a major hurricane in under 24 hours — has become more common, not less, in recent years. Equipment failures, fiber cuts, and power grid instability don’t wait for a forecast at all. If your disaster plan only activates once a storm is named and tracked, you’re already behind.

The Plan You Need Is the One That’s Already Running

At Bullroar, we’ve spent 25+ years building and securing network infrastructure in one of the most storm-exposed regions in the country — including offshore Gulf of America platforms where “we’ll deal with it when it gets closer” was never an option to begin with. What we’ve learned, over and over, is that the businesses who come through a disaster cleanly aren’t the ones who scrambled well. They’re the ones who never had to scramble, because resilience was already built into how their network operated on a normal Tuesday.

That means:

Redundant paths, not backup plans. If your network has a single point of failure — one upstream provider, one path to your data, one facility — you don’t have a disaster plan, you have a single incident away from an outage. Dual-datacenter architecture with real BGP multipath means traffic reroutes automatically. Nobody has to notice a storm hit for your network to keep functioning.

What This Looks Like Before the Storm, Not During It

The uncomfortable truth is that most of what actually protects a business during a disaster has to be in place weeks or months before there’s any storm to prepare for. By the time a hurricane is 48 hours out, you’re not building resilience — you’re finding out whether you already had it.

That’s really the point of a Cyber Threat Assessment: not to answer “are we ready for hurricane season,” but to answer “are we ready, period” — because the network and security posture that holds up against a ransomware attempt at 2 AM on an ordinary Tuesday is the same posture that holds up when a storm intensifies faster than anyone predicted.

When There’s No Storm at All

Everything above assumes you at least get *some* signal — a forecast, a cone, a few hours of warning even if it’s fewer than you’d like. But the scenario that actually breaks most disaster plans is the one with zero lead time: a building fire. A burst pipe that takes out a server room overnight. An electrical fault. None of these send out an advisory. None of these give you a five-day cone.

This is where the difference between “hurricane plan” and “disaster plan” really matters. A lot of businesses have the former and call it the latter. A hurricane plan says: evacuate by Tuesday, generators fueled, staff notified, primary site hardened. A fire at 2am on an ordinary Thursday doesn’t care about any of that — there’s no lead time to execute a single one of those steps.

If your resilience only kicks in when someone activates it, it isn’t resilience — it’s a checklist that depends on a warning you might never get.

The businesses that walk away from a total-loss event — the ones back online in hours instead of weeks — aren’t the ones who reacted well to the fire. They’re the ones whose infrastructure never depended on that building being there in the first place. Redundant paths, geographically separated sites, and current backups aren’t hurricane-specific measures. They’re what make a building fire a bad night instead of a company-ending event.

That’s really the test worth applying to any disaster plan: does it require you to see it coming? If the answer is yes, it isn’t a disaster plan — it’s a weather plan. The unplanned, unannounced version of a bad day is the one that actually determines whether your business survives.

Picture this: a system that was a tropical storm at your evening forecast is a major hurricane by morning, and it’s now on a track nobody expected 12 hours ago. Your team is scattered. Some people can get to the office; others can’t. Your primary facility loses commercial power. This isn’t a hypothetical — it’s happened on this coast before, and it will happen again.

In that scenario, there’s no time to configure failover, no time to test whether your backups actually restore, no time to figure out who has admin credentials to what. There’s only what was already built, tested, and running before anyone knew a storm was coming.

That’s the standard worth building toward — not “we have three days to prepare,” but “we don’t need three days.”

How Secure Is MFA, Really? The Weaknesses Nobody Talks About (And Why FIDO Is the Fix)

Aaron Wickware, 7/28/2026

Multi-factor authentication has become the baseline recommendation for basically every security framework, cyber insurance application, and compliance checklist out there — and for good reason, it stops the overwhelming majority of automated credential-stuffing attacks cold. But “MFA enabled” has quietly become shorthand for “secure,” and that’s not quite true anymore. Not all MFA is created equal, and attackers have gotten very good at working around the most common kind.

The MFA Most Businesses Are Actually Using

When most businesses say they “have MFA,” they mean one of two things: a one-time code sent by SMS text message, or a push notification to an authenticator app asking the user to approve or deny a login. Both are a real improvement over password-only security. Both are also increasingly the specific target of modern attacks.

Where SMS-Based MFA Breaks Down

SIM swapping. An attacker convinces (or bribes, or social-engineers) a mobile carrier into porting a victim’s phone number to a SIM card the attacker controls. Every SMS code now goes straight to the attacker, and the victim often doesn’t notice until their phone loses service entirely.

SS7 network exploitation. The signaling protocol that routes SMS messages between carriers has known, long-documented weaknesses that let sophisticated attackers intercept text messages in transit, without ever touching the victim’s phone.

Basic phishing. A fake login page asks for a username, password, and the SMS code in one motion. The victim types in the real code they just received, the attacker’s tooling relays it to the real site in real time, and the session is stolen before the code even expires.

None of this requires nation-state resources. SIM-swapping kits and real-time phishing relay tools are sold as commodity services on criminal forums today.

Where Push-Notification MFA Breaks Down

MFA fatigue attacks (“push bombing”). An attacker who already has a valid username and password sends repeated push notification requests — sometimes dozens in a row, sometimes late at night — until an exhausted or confused user finally taps “approve” just to make it stop. This exact technique has been behind several major, publicly reported enterprise breaches in the past few years.

Real-time phishing relay (adversary-in-the-middle). Just like the SMS version, a fake login page captures credentials and immediately triggers the real push notification, relaying the user’s approval straight through to the attacker’s session. The user believes they just logged into the real site. They didn’t.

The uncomfortable truth: both of these are examples of MFA “working exactly as designed” and still failing, because the weak point isn’t the cryptography — it’s that these methods ultimately rely on a human making a correct judgment call under pressure, in real time, often without enough context to make it.

Why FIDO2/WebAuthn (Passkeys) Are Fundamentally Different

FIDO2 — the standard behind hardware security keys and modern “passkeys” — doesn’t just add another factor for a human to approve. It changes the underlying mechanism entirely.

Phishing-resistant by design. A FIDO2 credential is cryptographically bound to the specific website or application it was created for. If a user lands on a convincing fake login page, the credential simply won’t work there — not because the user was careful, but because the protocol itself checks the origin before anything happens. There’s no code to relay and no approval prompt to trick someone into tapping.

Nothing to intercept. There’s no SMS message to reroute, no one-time code to phish, and no push notification to bomb someone into approving. The authentication happens through a cryptographic challenge-response between the device and the site — there’s simply no shared secret in transit for an attacker to capture.

No shared secret to steal from the server side, either. Traditional MFA methods and even passwords involve secrets that live on a server somewhere, which is exactly what shows up in breach dumps. FIDO2 uses public-key cryptography — the private key never leaves the user’s device, so there’s no equivalent server-side secret to steal in bulk.

Built into hardware most people already have. Modern passkeys don’t require buying a separate hardware token. Windows Hello, Touch ID, Face ID, and hardware security keys like YubiKeys all support FIDO2 natively, meaning the security upgrade often doesn’t require a hardware purchase or a steep learning curve for end users.

What This Means in Practice

This isn’t an argument for ripping out MFA — any MFA is still meaningfully better than none. It’s an argument for understanding that there’s a real hierarchy of strength:

1. Password only — weakest, offers essentially no protection against credential stuffing or reused passwords

2. SMS-based MFA — better, but vulnerable to SIM swapping, SS7 exploitation, and real-time phishing relay

3. Push-notification MFA — better still, but vulnerable to MFA fatigue attacks and phishing relay

4. FIDO2/WebAuthn (passkeys, hardware security keys) — the current gold standard, resistant to phishing and credential relay by design

For accounts that matter — admin access, email, financial systems, anything a cyber insurance carrier would ask about after an incident — the goal should be moving toward tier 4, not stopping at tier 2 or 3 and calling it done.

The Bottom Line

MFA isn’t broken, but a lot of businesses are relying on the weakest tier of it and assuming they’re fully covered. Attackers have adapted to SMS codes and push notifications faster than most security policies have. FIDO2 closes the gap by removing the human judgment call from the equation entirely — which is exactly the point, since the human judgment call is what attackers are targeting.

Evaluating which authentication methods are actually in use — and how exposed that leaves critical accounts — is a standard part of every Bullroar Cyber Threat Assessment Program engagement.

Latency vs. Jitter: What's Actually Killing Your Calls

Aaron Wickware, 7/21/2026

“Our internet feels slow” is one of the most common complaints we hear — and it’s almost never actually about speed. Most businesses have plenty of bandwidth. What they don’t have is a stable connection, and the difference between those two things is the difference between latency and jitter. Confusing them leads to buying the wrong fix.

Latency: The Delay

Latency is simply how long it takes a packet of data to get from point A to point B, usually measured in milliseconds. Every connection has some latency — it’s a function of physical distance, the number of network hops in between, and the speed of light itself. You can’t get it to zero, but you can get it low and, more importantly, consistent.

For most everyday tasks — web browsing, email, file downloads — latency in the range of 20-100ms is barely noticeable. Even up to 150ms, most people don’t consciously register the delay. Latency becomes a real problem in a narrow set of cases: real-time voice and video, competitive gaming, and specific low-latency-dependent applications like remote desktop control or industrial control systems.

Jitter: The Inconsistency

Jitter is the variation in latency over time — not how long packets take, but how unevenly they take that long. If your latency bounces between 20ms and 150ms from one packet to the next, that’s high jitter, even though the average latency might look fine on paper.

This is the one that actually wrecks calls.

Why Jitter Is the Real Killer

Real-time audio and video are built on the assumption that packets will arrive at a roughly steady rate. Your phone or laptop buffers a small amount of incoming audio to smooth out minor timing differences — but when jitter exceeds what that buffer can absorb, packets arrive too late to be used, or arrive out of order and get discarded. The result is the symptom everyone recognizes instantly: choppy audio, robotic-sounding voices, video that freezes and skips, or calls that drop mid-sentence.

Here’s the part that trips people up: a connection with higher but consistent latency will often sound and feel better than a connection with lower but erratic latency. A steady 80ms connection is usually fine for a video call. A connection that swings unpredictably between 15ms and 120ms — even though it’s “faster” on average — will produce noticeably worse call quality, because the jitter buffer can’t keep up with the swings.

This is why “we upgraded our bandwidth and the calls still cut out” is such a common complaint. More bandwidth doesn’t fix jitter. You can have a gigabit connection with terrible jitter and a 50-megabit connection with none — and the 50-megabit connection will sound better on every call.

What Causes Jitter in the First Place?

– Network congestion — traffic competing for the same limited path, especially during peak usage hours

– Route changes mid-session — traffic taking a different path packet to packet instead of a consistent route

– Oversubscribed or shared circuits — common on lower-tier business internet plans where bandwidth is shared unpredictably with other customers

– Too many hops — every additional network boundary a packet crosses is another opportunity for inconsistent handling

– QoS Misconfiguration — voice and video traffic competing on equal footing with a large file backup or software update happening at the same time

How to Actually Fix It

Quality of Service (QoS) configuration. Properly configured QoS prioritizes real-time voice and video traffic ahead of less time-sensitive traffic like backups or downloads, so a large file transfer doesn’t starve a client call of bandwidth at the wrong moment.

A more direct network path. This is where direct-to-transit connectivity (see our earlier post on this) genuinely helps — fewer hops between your network and the destination means fewer opportunities for jitter to creep in along the way.

Dedicated bandwidth over shared circuits. If your connection is sharing capacity with other tenants or customers, congestion at their end can show up as jitter on your calls even though nothing changed on your side.

Proper monitoring, not guesswork. Most businesses find out about a jitter problem from a frustrated employee or an angry client on a dropped call. Proactive network monitoring catches jitter trending upward before it becomes a pattern people notice.

The Bottom Line

If your team is complaining about choppy calls or laggy video despite “plenty of bandwidth,” the fix almost certainly isn’t a bigger pipe — it’s a more stable one. Latency tells you how far away something is. Jitter tells you how reliable the road is to get there. For anything real-time, jitter is usually the one actually doing the damage.

This is exactly the kind of thing that shows up in a network assessment but never shows up on a speed test — which is why we look at both latency *and* jitter, not just raw throughput, as part of every Bullroar Cyber Threat Assessment Program engagement.

Still Running IKEv1? It's Time to Migrate to IPsec with Stronger Ciphers

Aaron Wickware, 7/14/2026

If your site-to-site VPNs or remote access tunnels were set up more than a few years ago, there’s a good chance they’re still running on IKEv1 with encryption settings nobody has touched since the day they were configured. That’s a problem — not because it was wrong at the time, but because “good enough in 2018” doesn’t hold up against what’s attacking networks today.

At Bullroar Telecom, migrating clients from legacy IKEv1 tunnels to IKEv2 with modern cipher suites is one of the most common — and most impactful — changes we make during a network security engagement.

What’s Actually Wrong with Older VPN Configurations

A lot of VPN tunnels built years ago are still leaning on defaults that were considered acceptable at the time: 3DES or AES-128 in CBC mode, SHA-1 for integrity checking, and IKEv1 for key exchange. None of these are broken in the sense of “an attacker will crack it tomorrow” — but all of them are weaker than what’s readily available today, and every one of them is on the deprecation path across major vendors, compliance frameworks, and cyber insurance requirements.

IKEv1 itself carries real operational baggage too: slower renegotiation, weaker built-in support for NAT traversal, and none of the resilience improvements that came with its successor.

Why IKEv2 Is the Better Foundation

Faster, more reliable reconnection. IKEv2 supports MOBIKE, which allows a VPN session to survive a change in the underlying network path — a laptop switching from WiFi to cellular, or a failover to a backup circuit — without dropping and rebuilding the tunnel from scratch.

Simpler, more resilient negotiation. IKEv2 uses fewer exchanges to establish a tunnel than IKEv1, which means faster setup and less surface area for negotiation failures.

Built-in dead peer detection. IKEv2 handles dead peer detection natively, so a failed remote endpoint gets identified and failed over faster, instead of leaving a tunnel hung in a half-open state.

Why the Cipher Suite Matters Just as Much

Upgrading the key exchange protocol without upgrading what’s actually encrypting the traffic only gets you halfway there. As part of every IKEv2 migration, we move clients to modern, vetted cipher suites:

– AES-256-GCM for encryption — an authenticated encryption mode that combines confidentiality and integrity checking in a single, efficient pass, replacing older AES-CBC plus separate HMAC configurations

– SHA-384 or SHA-256 for integrity, retiring SHA-1 wherever it’s still lingering

– ECDHE (Elliptic Curve Diffie-Hellman) for key exchange, which delivers stronger security per bit than traditional Diffie-Hellman groups while being computationally lighter

– Perfect Forward Secrecy (PFS) enforced on every tunnel, so that even if a long-term key were ever compromised, previously captured traffic stays unreadable

Why This Isn’t Just a Compliance Checkbox

Cyber insurance carriers are increasingly asking pointed questions about VPN configurations during renewal — and “we’re still on IKEv1 with default ciphers” is exactly the kind of answer that gets a policy flagged or a premium increased. Beyond insurance, this is genuinely one of the more cost-effective security upgrades available: it doesn’t require new hardware in most cases, doesn’t change how end users connect, and closes a real gap without disrupting operations.

How the Migration Actually Works

This isn’t a rip-and-replace project. At Bullroar, we handle IKEv2 migrations methodically:

1. Audit existing tunnels to identify which sites and remote users are still on legacy configurations

2. Stage the new configuration on a parallel tunnel where possible, so there’s no gap in connectivity

3. Cut over during a low-impact window, with rollback ready if anything doesn’t negotiate cleanly on the far end

4. Verify and document the new cipher suite and key exchange settings for your records — useful for the next insurance renewal or compliance audit

Because our infrastructure runs on Fortinet, we’re able to standardize these upgrades using the same platform we already manage day to day, rather than bolting on a separate VPN appliance or vendor.

The Bottom Line

If nobody can remember the last time your VPN configuration was reviewed, it’s worth a look. Migrating from IKEv1 to IKEv2 with modern cipher suites is a targeted, low-disruption upgrade that closes a real security gap — and it’s exactly the kind of thing that gets caught, free of charge, in a Bullroar CTAP assessment.

Data Loss Prevention: Why You Need It, and How Fortinet Works With Microsoft to Deliver It

Aaron Wickware, 7/7/2026

Most small and mid-sized businesses think about cybersecurity as keeping attackers out. That’s half the picture. The other half — the one that gets far less attention until something goes wrong — is keeping your own data from leaving in the first place, whether that’s an employee accidentally emailing a spreadsheet full of customer SSNs to the wrong address, a departing employee copying a client list to a personal drive on their way out, or malware quietly exfiltrating files in the background.

That’s what Data Loss Prevention (DLP) is for. And if your business already runs on Microsoft 365, you likely have more of the foundation for it than you realize — it just isn’t configured to actually work yet.

What Data Loss Prevention Actually Means

DLP isn’t a single product — it’s a set of policies and technical controls that identify sensitive data (SSNs, credit card numbers, health records, contract terms, source code, whatever matters to your business) and control what happens to it: where it can be stored, who can access it, whether it can be emailed outside the company, and whether it can be copied to a USB drive or personal cloud account.

Done well, DLP doesn’t just block bad actors — it catches the far more common scenario: a well-meaning employee who makes a mistake. Industry data consistently shows that a large share of data loss incidents are accidental, not malicious. A DLP policy that flags “hey, this email has 200 SSNs in it, are you sure?” stops far more incidents than any firewall rule ever will.

Why This Matters Even If You’ve Never Had an Incident

Regulatory exposure. If your business handles healthcare data, financial information, or insurance records, there’s very likely already a regulatory requirement — HIPAA, GLBA, state insurance data security laws — mandating that you have controls in place to prevent unauthorized disclosure. Not having them isn’t a gray area; it’s a gap that shows up the moment you’re audited or breached.

Cyber insurance underwriting. Carriers are increasingly asking directly whether DLP controls are in place before issuing or renewing a policy. Not having an answer can mean a higher premium — or no coverage at all.

Insider risk is real risk. Firewalls and endpoint protection are built to stop outside threats. They don’t do much against an authorized user moving data somewhere it shouldn’t go, whether by mistake or intentionally on their way out the door.

The cost of a slow discovery. The businesses hit hardest by data loss aren’t usually the ones with the biggest breach — they’re the ones who didn’t know it happened for months. DLP tooling gives you visibility into what’s actually leaving your network, so a leak gets caught in hours, not discovered by a customer complaint six months later.

How Fortinet and Microsoft Work Together

This is where the pieces click into place for businesses already running Microsoft 365 or Azure. Fortinet’s security fabric is built to integrate directly with Microsoft’s ecosystem rather than compete with it, which means you’re not ripping out what you already have — you’re closing the gaps around it.

Microsoft Purview DLP + Fortinet network enforcement. Microsoft Purview already has the ability to classify sensitive data inside Exchange, SharePoint, OneDrive, and Teams. Fortinet extends that visibility and control out to the network layer — inspecting traffic as it leaves your environment, not just as it moves within Microsoft’s cloud, so sensitive data is caught whether it’s headed out through email, a web upload, or an unsanctioned cloud app.

FortiGate SSL inspection paired with Microsoft Information Protection labels. When files are labeled as sensitive in Microsoft’s ecosystem, FortiGate firewalls can inspect encrypted traffic and enforce policy based on those labels — blocking or flagging attempts to move labeled data outside approved channels, even over encrypted connections.

Identity-aware policy through Azure AD (Entra ID) integration. Fortinet’s fabric integrates with Microsoft Entra ID, meaning DLP and access policies aren’t just about the data itself — they factor in who’s requesting it, from what device, and under what conditions. A file that’s fine for a laptop on the corporate network can be automatically restricted from a personal device on public WiFi.

Unified logging and alerting. Instead of DLP alerts living in Microsoft’s console and network alerts living in a separate Fortinet dashboard, the two can be correlated — so a suspicious download flagged in Microsoft 365 and an unusual outbound transfer flagged by FortiGate can be connected as a single incident instead of two disconnected data points nobody notices.

What This Actually Looks Like for a Small Business

You don’t need an enterprise security team to run this. In practice, a properly configured DLP setup means:

– Sensitive data types (SSNs, credit cards, health records, or custom patterns specific to your business) are automatically identified across email, file storage, and network traffic

– Policies are set once — block, warn, or quarantine — and apply consistently whether data is moving through Outlook, a web upload, or a USB drive

– Alerts go to the right people immediately, not buried in a report nobody reads

– The whole system is monitored as part of ongoing management, not configured once and forgotten

The Bottom Line

If your business already runs on Microsoft 365, you’re not starting from scratch — you’re sitting on classification and protection tools that are almost certainly under-configured or entirely unused. Pairing that with Fortinet’s network-level enforcement closes the loop: data gets classified, tracked, and controlled everywhere it moves, not just inside Microsoft’s walls.

This is exactly the kind of gap our Cyber Threat Assessment Program is built to catch — a complimentary look at where your data actually is, where it could leak, and what it would take to close that gap without disrupting how your team works.

What Is DLP, and Why Do You Need It?

Aaron Wickware, 6/30/2026

Most security spending goes toward keeping people out. Firewalls, intrusion prevention, endpoint protection — all of it built around the assumption that the threat is external. Data Loss Prevention (DLP) is built around a less comfortable assumption: sometimes the problem isn’t someone breaking in, it’s your own data walking out the front door, on purpose or by accident.

What DLP Actually Does

DLP is a set of tools and policies that monitor, detect, and block sensitive data from leaving your organization in ways it shouldn’t. That’s a broad definition on purpose, because DLP operates across several different surfaces at once:

– Email — flagging or blocking outgoing messages that contain Social Security numbers, credit card data, or other sensitive patterns

– Endpoints — controlling whether sensitive files can be copied to a USB drive, uploaded to a personal cloud account, or printed

– Network traffic — inspecting outbound traffic for data that matches sensitive patterns, even when it’s leaving over an encrypted connection

– Cloud applications — policies applied inside platforms like Microsoft 365, controlling how files are shared, labeled, and moved between SharePoint, OneDrive, and Teams

The common thread is content inspection: DLP tools look at what’s actually inside a file or message — not just where it’s going — and compare it against rules. Does this document contain something that matches a Social Security number pattern? A specific classification label? Language from a contract marked confidential? If so, the policy decides what happens next: block it, encrypt it, warn the user, or just log it for later review.

Why This Isn’t Just an IT Problem

Most data loss isn’t a dramatic hack. It’s an employee attaching the wrong spreadsheet to an email. It’s a departing employee taking a client list to a competitor. It’s a well-meaning staff member uploading a folder of files to a personal Google Drive because it’s easier to work from home that way. None of that requires a sophisticated attacker — it requires one person, one moment of carelessness or intent, and no control in place to catch it.

That’s the case for DLP that doesn’t require citing a single breach statistic: the overwhelming majority of data loss incidents involve someone who already had legitimate access to the data in the first place.

The Regulatory Angle

For a lot of industries, DLP isn’t optional in any practical sense. HIPAA-covered practices have to demonstrate reasonable safeguards around protected health information. Financial services firms answer to GLBA. Businesses handling payment card data have PCI-DSS obligations. Louisiana’s own data privacy law, along with the newer legislation set to take effect in 2027, adds another layer of expectation around how personal data gets handled and protected.

Regulators generally don’t ask whether a breach was malicious or accidental — they ask whether reasonable controls were in place. A DLP policy that would have caught the mistake is exactly the kind of control that shows up in that conversation.

What a Real DLP Setup Looks Like

The tools matter less than the discipline behind them, but in practice, effective DLP usually combines:

1. Data classification — knowing what’s sensitive in the first place. You can’t protect what you haven’t identified.

2. Policy enforcement at multiple layers — email, endpoint, network, and cloud, since sensitive data can leave through any of them.

3. Visibility over vague blocking — a lot of effective DLP starts as monitoring and alerting rather than hard blocks, both to avoid disrupting legitimate work and to understand actual data flow before locking things down.

4. Integration with identity — modern platforms like Microsoft Purview tie DLP policies to identity and access controls in Entra ID, so protection follows the user and the data, not just a network location.

The Honest Trade-Off

DLP done poorly is annoying — false positives that block legitimate work, policies too broad to be useful, or too narrow to catch anything real. DLP done well is mostly invisible, quietly doing its job until the one time it catches something that would have been a very bad day otherwise.

That’s the pitch, really: it’s insurance that occasionally saves you from yourself, not just from someone else.

Security Awareness Training: It's Not Optional

Aaron Wickware, 6/23/2026

Every layered security stack — firewalls, DLP, endpoint protection, email filtering — is built to defend against the same weak point: a person clicking something they shouldn’t have. You can spend a fortune on hardware and still lose to a well-crafted email that asks someone in accounting to “confirm” a wire transfer.

That’s not a knock on your people. It’s just math. Attackers only need one person to make one mistake, one time. Your defense needs to work every single time. That asymmetry is exactly why security awareness training isn’t a nice-to-have — it’s the control that determines whether every other control you’ve paid for actually gets a chance to work.

The Numbers Behind the Claim

Phishing remains the leading initial access vector in the overwhelming majority of breaches tracked industry-wide, year after year. Not zero-days. Not exotic malware. Email. A message that looks close enough to legitimate that someone clicks, enters credentials, or opens an attachment before their brain catches up to what their eyes just saw.

Ransomware groups know this better than anyone — most major ransomware incidents trace back to a phishing email, a compromised credential from a prior phishing campaign, or an exposed remote access tool that a user was tricked into approving. The technical sophistication tends to happen after the initial foothold, not to get it.

Why “We sent an email about it once” Doesn’t Count

A lot of organizations check the compliance box with an annual video and a quiz nobody remembers a month later. That satisfies an auditor. It does very little for actual behavior change, because:

– One-time training decays fast. Retention on security concepts drops sharply within weeks without reinforcement.

– Real attacks don’t look like training examples. Attackers adapt faster than annual curricula do. A phishing simulation about a fake IT password reset doesn’t prepare someone for a spoofed vendor invoice using real details pulled from a LinkedIn profile.

– It skips the moment that actually matters. The value of training isn’t the content — it’s whether someone pauses for two extra seconds on the one email, out of thousands, that’s actually dangerous.

What Effective Training Actually Looks Like

– Ongoing, not annual. Short, frequent touchpoints beat a single long session — the same reason spaced repetition works better than cramming for anything else.

– Simulated phishing campaigns. Regular, realistic simulated attacks, with immediate, non-punitive feedback when someone clicks. The goal is a teachable moment, not a shame spiral that makes people hide mistakes instead of reporting them.

– Role-specific content. Finance staff need to recognize wire fraud and invoice manipulation. Front desk staff need to recognize pretexting and tailgating. A one-size-fits-all module misses both.

– A clear, easy reporting path. If someone suspects a phishing email, the button to report it should be one click away — and reporting should be treated as a win, not an inconvenience to IT.

– Leadership participation. Executives are disproportionately targeted (whaling) and disproportionately likely to skip training they consider beneath them. That’s exactly backwards from where the risk actually concentrates.

The Regulatory Reality

For a lot of industries, this isn’t just best practice anymore. HIPAA-covered practices, GLBA-regulated financial institutions, and businesses under frameworks like PCI-DSS increasingly expect documented, ongoing security awareness training as part of demonstrating reasonable administrative safeguards. When regulators or auditors ask “what have you done to prevent this,” a dusty annual training certificate from eighteen months ago is a weak answer.

The Bigger Point

No firewall reads the email before the human does. No DLP policy stops someone from willingly typing their password into a convincing fake login page. Every technical control downstream of a phishing click is playing defense against something that a trained, alert person could have stopped in the first two seconds.

That’s the actual argument for security awareness training. It’s not a compliance checkbox sitting next to the real security work — it’s the first line of the real security work.

What We Run

Everything above isn’t theoretical for us — it’s the checklist we hold our own security awareness training against, which is why we run Huntress Managed SAT for our clients. It covers the bases laid out here and then some: ongoing, bite-sized training rather than a single annual slog, realistic simulated phishing campaigns with immediate feedback instead of a shame-and-blame approach, and reporting built to make flagging a suspicious email effortless rather than a hassle nobody bothers with. It’s backed by the same team behind Huntress’s managed detection and response platform, so the training side and the “someone’s actually watching for threats” side aren’t two disconnected vendors — they’re part of the same feedback loop.

If your current training program is an annual video and a quiz nobody remembers a month later, this is the upgrade path.

Deep Packet Inspection: The Legitimate Man in the Middle

Aaron Wickware, 6/16/2026

“Man in the middle” is supposed to be a bad thing. It’s the phrase we use for an attacker quietly sitting between two parties who think they’re talking directly to each other — reading, and sometimes altering, everything that passes between them. It’s the reason SSL stripping, rogue Wi-Fi access points, and ARP spoofing show up on every security awareness slide deck ever made.

Deep Packet Inspection (DPI) does the exact same thing. On purpose. With your blessing.

What DPI Actually Does

Traditional firewalls make decisions based on packet headers — source IP, destination IP, port number. That’s like deciding whether to let a package into a building based only on the shipping label. DPI opens the box.

It inspects the actual payload of network traffic — the contents of the packet, not just the address information wrapped around it — and makes decisions based on what’s really inside: application type, protocol behavior, embedded signatures, known malware patterns, even the structure of encrypted handshake negotiations before full encryption kicks in.

That’s the difference between a firewall rule that says “allow port 443” and a firewall that can say “allow port 443, but not if this is actually a tunneled VPN protocol disguised as HTTPS, and not if the payload matches a known exploit signature, and not if this connection is exfiltrating data to a domain that was registered six hours ago.”

Why “Man in the Middle” is the Right Description

When DPI inspects encrypted traffic — TLS/SSL, most commonly — it has to do something that looks, mechanically, identical to an attack: it terminates the original encrypted session, inspects the plaintext, and re-encrypts it before sending it on. The firewall presents its own certificate to the internal client and negotiates a separate encrypted session to the external destination. Two encrypted tunnels, stitched together in the middle, with a brief moment of visibility in between.

This is precisely the mechanism behind a malicious SSL MITM attack. The only difference is who’s holding the scissors and why. Done by an attacker, it’s a breach. Done by your own firewall, with your own root certificate trusted on your own managed endpoints, inspecting your own traffic on your own network, it’s a security control.

The technique is identical. The trust relationship is what makes it legitimate.

What This Buys You

Without SSL inspection, an increasingly large share of network traffic is simply invisible to your firewall — both the good and the bad. Most malware, most command-and-control traffic, most data exfiltration in 2026 rides over HTTPS, precisely because so many organizations still don’t inspect it. A firewall that can’t see inside encrypted traffic is a firewall that’s mostly reading shipping labels.

DPI (and specifically SSL/TLS inspection) is how a modern firewall actually earns the word “next-generation”: application awareness, intrusion prevention that works on real payloads instead of guessing from ports, and the ability to catch threats that are deliberately hiding inside traffic that looks perfectly normal from the outside.

The trade-offs, because there always are some

– Performance cost. Decrypting, inspecting, and re-encrypting every session in real time is computationally expensive. This is exactly why dedicated security processing hardware exists rather than relying on general-purpose CPUs to do it.

– Certificate trust management. Every managed device needs to trust the inspecting firewall’s internal CA certificate, or users get constant certificate warnings — which trains people to click through security warnings, which is its own problem.

– Privacy and policy boundaries. Not everything should be decrypted. Banking and healthcare traffic, for instance, often gets carved out via policy exceptions for both regulatory and trust reasons. Knowing what to inspect and what to deliberately leave alone is as much a policy decision as a technical one.

The Bigger Point

Security tooling borrows attacker techniques constantly — penetration testing is authorized hacking, honeypots are deliberate bait, and DPI is a sanctioned man-in-the-middle. The pattern is always the same: the technique isn’t inherently good or bad, the authorization and intent around it are what matter.

That’s worth remembering any time a security control looks, on paper, uncomfortably close to the thing it’s supposed to be defending against.

A Message From Bullroar, To The People Who Keep This Country Running

Aaron Wickware, 6/9/2026

Business is hard. That’s not a complaint — it’s just the truth, and if you’re reading this, you already know it better than I could tell you.

Supply chains snap without warning. Fuel costs swing. Tariffs shift the math on a Tuesday and you’re re-pricing by Thursday. Every hardworking man and woman I know — hard hat, steel toe, dress shoes, doesn’t matter what collar you’re wearing — is standing on ground that moves. That’s not new. That’s the nature of running something real. And I’ll say this plainly: I’m America First, and I’ll sacrifice what needs sacrificing to keep this country — and what we’ve built here — strong for our kids. But that conviction doesn’t pay your invoices or patch your network, and neither does hoping for the best.

Here’s the part nobody wants to say out loud, so I will.

The 30-Second Pitch Isn’t a Plan

Somewhere out there right now, someone is sitting across from a business owner with a slide deck, a firm handshake, and a 30-second pitch about “network security” and “business continuity.” It sounds great. It feels responsible. The owner signs, feels like the box is checked, and goes back to running the business they actually understand — because that’s their job, not ours.

And that owner walks away pretty sure, reasonably confident, almost certain they’re covered.

They are not.

I’m not saying this to scare anybody or to sell fear — I genuinely don’t think that works, and I don’t respect it as a tactic. I’m saying it because I’ve spent 25+ years with my hands actually inside the infrastructure. We built our name offshore in the Gulf, where “we’ll get to it tomorrow” isn’t an option because tomorrow the rig still needs to talk to shore — and that’s a mindset, not just a market. Whether it’s a rig, a manufacturing floor, a hospital, a law office, a distribution warehouse, or a small shop with three registers and a back office — the stakes are different, but the physics are the same. I’ve seen what a real failure looks like, and I’ve seen what a fake sense of security looks like right up until the moment it isn’t. They don’t look the same up close, but from thirty feet away — from that once-a-year sales meeting — they look identical, no matter what industry you’re in.

The Precipice is the Job

Every business is closer to the edge than the calm Tuesday makes it feel. That’s not pessimism, it’s just physics. One bad actor, one storm, one hardware failure at 2 AM, one supply chain hiccup that leaves you without the part you needed yesterday — and the difference between “we handled it” and “we’re finished” usually comes down to decisions that were made, or weren’t made, months before anyone knew there was a problem.

The companies that survive aren’t the ones that never get close to the edge. They’re the ones who built something that holds when they get there.

What We Actually Do About It

We’re not in the business of feel-good slides. We’re in the business of building the thing underneath them — the routing, the redundancy, the failover, the actual engineering — so that when the bad day comes, and it will, you’re not finding out in real time whether your “solution” was ever real.

That’s what Bullroar has done for over 25 years — born offshore in the Gulf, now standing behind businesses across every industry we serve — and it’s what we’ll keep doing: the unglamorous, hands-on work of making sure the lights stay on when everything else is going sideways. No hype. No 30-second pitch. Just the people who actually built it, still here, still on call, no matter what your business does.

You built something worth protecting. We take that seriously — because we know exactly what it costs you if we don’t.

We’ve got your back.

-Aaron

President, Bullroar Telecom

Quantum Computing Is Coming for Your VPN — Here's Why Quantum-Safe IPsec Can't Wait

Aaron Wickware, 6/2/2026

The Threat Isn’t Science Fiction Anymore

For years, “quantum computers will break encryption someday” has sounded like a problem for the next decade. It isn’t.

It’s a problem for today’s traffic. Here’s the uncomfortable part: an attacker doesn’t need a working quantum computer right now to hurt you later. They just need to record your encrypted traffic today and decrypt it once the technology catches up. Security researchers call this harvest-now-decrypt-later — and it’s already happening. Nation-states and well-funded threat actors are quietly capturing VPN traffic, site-to-site tunnel data, and encrypted backups, banking on the fact that a “cryptographically relevant quantum computer” will eventually make today’s Diffie-Hellman and RSA key exchanges trivial to unwind.

If your organization moves anything sensitive over an IPsec VPN — financial records, engineering data, client files, offshore operations data — that traffic could already be sitting in someone’s archive, waiting.

What Actually Breaks

Classic IPsec key exchange (IKEv2) leans on Diffie-Hellman and elliptic-curve math. That math is currently unbreakable by any conventional computer. It is not unbreakable by a sufficiently powerful quantum computer running Shor’s algorithm. Once that hardware matures, the key exchange that protects your VPN tunnels stops being a wall and starts being a formality.

Symmetric encryption (AES) holds up reasonably well against quantum attacks. Key exchange does not. That’s the part of the handshake that needs to change — and the industry is already moving.

The Fix: Post-Quantum Hybrid Key Exchange

The IETF has already standardized the path forward. RFC 9370 extends IKEv2 to allow multiple key exchanges within a single IKE SA negotiation, and a companion draft defines how to fold NIST’s ML-KEM (the standardized post-quantum key encapsulation mechanism, formerly known as Kyber) into that exchange alongside traditional elliptic-curve Diffie-Hellman.

This combined approach — called PQ/T Hybrid key exchange — is deliberate. Instead of ripping out proven classical cryptography and betting everything on algorithms that are still relatively new, hybrid key exchange runs both simultaneously. Your tunnel is only as breakable as the stronger of the two methods. If ML-KEM ever turns out to have a flaw nobody’s found yet, the classical exchange still protects you. If a quantum computer eventually breaks the classical exchange, ML-KEM still protects you.

A few practical notes for anyone planning a migration:

– ML-KEM comes in three strengths — ML-KEM-512, -768, and -1024 — mapped to NIST security levels roughly equivalent to AES-128, AES-192, and AES-256.

– Packet size matters. ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts can exceed typical network MTU, which is why the IETF added the IKE_INTERMEDIATE exchange (RFC 9242) — it gives large post-quantum key material room to travel without breaking existing packet handling.

– Performance impact is minimal. IPsec tunnels stay up for long stretches and move large volumes of data relative to the one-time cost of the key exchange, so the extra math at negotiation time is a rounding error in practice.

– This is already shipping in real firewalls. Fortinet’s FortiOS supports PQC-hybrid IPsec key exchange today, letting administrators select up to three post-quantum KE groups per negotiation round alongside classical Diffie-Hellman. Cisco and Palo Alto Networks are on the same path.

What This Means for a Mid-Size Business

If you’re running a lean IT team without a dedicated cryptography specialist, here’s the honest read: you don’t need to panic, but you do need a plan. The transition to quantum-safe IPsec isn’t a single flag you flip — it’s a coordinated update across every VPN endpoint your organization touches: site-to-site tunnels between offices, remote access VPNs for staff, and any partner or vendor tunnels carrying sensitive data.

A few things worth doing now, well before this becomes an emergency:

1. Inventory your VPN endpoints. Know which firewalls, routers, and VPN concentrators are handling IPsec traffic and whether their firmware supports RFC 9370 hybrid key exchange.

2. Check your firmware and licensing. Post-quantum support is a firmware-level capability. If you’re running older code, this is one more reason to get current.

3. Prioritize by sensitivity, not convenience. Tunnels carrying financial, legal, health, or regulated data should move to hybrid key exchange first — not whichever tunnel is easiest to touch.

4. Don’t wait for a mandate. Financial services and defense-adjacent industries are already seeing early compliance pressure toward quantum-resistant cryptography. Being ahead of that curve costs a lot less than scrambling to catch up.

Where This Fits Into a Bigger Picture

Quantum-safe key exchange is one piece of a much larger security posture — but it’s a piece that’s easy to overlook because the payoff isn’t visible today. Nobody sees the traffic that was harvested two years ago sitting in an adversary’s archive. That’s exactly what makes it dangerous.

This is the kind of gap a network security assessment is built to catch: not just “is your firewall configured correctly today,” but “are you positioned for the threats that are already in motion.” If you don’t know whether your VPN infrastructure supports hybrid post-quantum key exchange, that’s a five-minute conversation worth having before it becomes a much longer one.

Bullroar Telecom provides managed network security and engineering services built on Fortinet infrastructure, including our Cyber Threat Assessment Program (CTAP) — a complimentary evaluation of your network’s real-world security posture.

The Internet Is Full of Scavenger Hunts. Here's How to Find Them.

Aaron Wickware, 5/26/2026

Every so often we like to step away from firewalls and failover configs and talk about something just plain fun. This week: internet scavenger hunts — the strange, sprawling world of puzzles, hidden pages, and rabbit holes that people have been building into the web since roughly the moment the web existed.

What counts as an internet scavenger hunt?

Broadly, three flavors:

Alternate Reality Games (ARGs). Elaborate, often years-long puzzles woven across websites, phone numbers, forums, and real-world locations. The most famous is probably Cicada 3301, which appeared in 2012 as a cryptic image posted to an anonymous forum and spiraled into a labyrinth of steganography, prime numbers, Mayan numerals, and physical flyers taped to lampposts in a dozen countries. Nobody has ever definitively confirmed who ran it or why. That mystery is basically the whole appeal.

Website Easter eggs. Smaller-scale, usually built by developers with a sense of humor and a little spare time. Google’s search bar still responds to commands like “do a barrel roll” and “askew.” Type the Konami code on plenty of sites and something changes. These are low-stakes hunts — no prime numbers required, just curiosity and a willingness to poke at things.

Geocaching and location-based hunts. The physical-world cousin, where GPS coordinates lead to hidden containers stashed in parks, under bridges, and in suspiciously specific tree stumps. There are millions of active caches worldwide, logged and tracked by a community that treats it with startling seriousness.

Why do people build these things?

Mostly for the same reason anyone builds anything elaborate and useless: because it’s satisfying to make something only a few people will ever fully understand. There’s also a real craft to it — a good puzzle has to be hard enough to resist a five-minute Google search, but not so hard that nobody ever solves it. That balance is harder to hit than it sounds.

If you want to try one:

– Cicada 3301 archives are still online and well-documented, if you want to see how deep a puzzle can go.

– Geocaching.com has a free tier and probably a cache within walking distance of wherever you’re reading this.

– Keep an eye on 404 pages — some companies use them as a spot for a hidden joke or puzzle, precisely because almost nobody looks there.

There’s a certain kind of mind that likes taking things apart to see how they work, whether that’s a cryptic puzzle, an old website’s source code, or — if we’re being honest about what pays the bills around here — a network that’s been humming along fine for years and nobody’s quite sure why. Same instinct, different Tuesday.

That’s it for this one. No pitch, no CTAP mention, just wanted to share something fun.

FortiBleed Wasn't About Weak Passwords. It Was About Exposed Management Interfaces.

Aaron Wickware, 5/19/2026

What Actually Happened

In June 2026, security researchers uncovered a sprawling credential-harvesting operation targeting Fortinet FortiGate firewalls and VPN gateways. Dubbed “FortiBleed,” the campaign compiled a verified database of tens of thousands of working administrator and VPN credentials — estimates from different researchers ranged from roughly 30,000 to over 86,000 compromised devices across 194 countries. The victim list reads like a roll call of global industry, and it wasn’t confined to small, under-resourced organizations.

Here’s the headline that matters more than the number: there was no new Fortinet vulnerability involved. No zero-day, no novel exploit. Researchers were explicit about this. What made FortiBleed effective wasn’t sophistication — it was scale. Attackers scanned the internet for exposed FortiGate devices, intercepted SSL-VPN authentication hashes, cracked them offline on a dedicated GPU cluster running well over a billion attempts, and tried curated lists of previously leaked passwords against every device they found. Once inside, the compromised device became a launchpad for harvesting the next set of credentials, creating a self-sustaining cycle.

The Story Everyone’s Telling Is Slightly Wrong

Most of the coverage has framed this as an SSL-VPN problem, and as a password-hygiene problem. Both are true, but neither is the actual root cause — and the distinction matters if you’re deciding what to fix.

UK’s National Cyber Security Centre described the exposure as brute-force, dictionary, and credential-stuffing activity against internet-facing FortiGate and VPN portals — language that includes the management interface, not just SSL-VPN specifically. And the remediation guidance from multiple security researchers backs that up: reset administrator accounts and local user accounts, not only SSL-VPN credentials; upgrade FortiOS to force migration off legacy SHA-256 password hashing onto PBKDF2; and — as a separate, non-negotiable step — block external access to FortiGate management interfaces entirely.

That last point is the one that gets buried. An organization that migrated off SSL-VPN but still has HTTPS or SSH admin access reachable from the internet hasn’t actually closed the door. They’ve just changed which room the attacker walks into. Credential rotation on a device that’s still internet-facing resets the clock — it doesn’t stop the next scan from finding it.

The Actual Common Denominator

Pull back far enough across the reporting and a pattern emerges that has nothing to do with password complexity: the organizations that got swept up in FortiBleed had an exposed management interface, an unrestricted admin ACL, or both. A strong password doesn’t help much if the login page it protects is reachable by anyone on the internet running an automated scanner. A weak or reused password matters enormously if that same login page is wide open. Either way, the exposure — not the password — is the precondition.

We haven’t seen a single fully hardened deployment fall into this category. No internet-facing management interface, tightly scoped admin ACLs, current firmware, rotated credentials on a real schedule — check every one of those boxes and FortiBleed simply isn’t a candidate risk, regardless of how the campaign evolves next.

None of Bullroar’s managed customers were exposed to FortiBleed. Not because we got lucky on timing, but because the fundamentals — locked-down admin access, no internet-facing management interfaces, current patch levels — were already in place before the campaign started.

The Real Checklist

If you’re running Fortinet infrastructure (managed by us or otherwise), here’s what actually matters, in order:

1. Confirm your management interface isn’t internet-facing. HTTPS and SSH admin access should never be reachable from the public internet. This is the single highest-leverage fix on this list.

2. Lock down admin access with ACLs. Even where remote management is necessary, restrict it to specific trusted source IPs — not “any.”

3. Rotate credentials on a real schedule, not just after an incident makes headlines. Assume any credential that’s been sitting unchanged for years is already circulating somewhere.

4. Get current on firmware and force the hash migration. Older FortiOS versions may still be using legacy SHA-256 password hashing; current patches support migration to PBKDF2, but that migration only happens after you log in post-upgrade — it isn’t automatic.

5. Don’t treat SSL-VPN as the whole threat model. Moving off SSL-VPN is a reasonable architectural decision for other reasons, but it doesn’t substitute for closing off the management interface itself.

Why This Matters Beyond FortiGate

FortiBleed is a Fortinet story this month. The pattern behind it — internet-exposed management interfaces plus stale credentials — isn’t specific to any one vendor, and it won’t be the last campaign to exploit exactly this combination. The organizations that keep sitting out these campaigns aren’t the ones with the most exotic defenses. They’re the ones that got the boring fundamentals right and kept them right.

Bullroar Telecom manages Fortinet infrastructure for our clients with locked-down admin access, no internet-facing management interfaces, and current firmware as standard practice — not an add-on. If you’re not certain where your own deployment stands on these fundamentals, that’s worth finding out before the next campaign, not after.

Will IPv4 Really Ever Die? Do You Actually Need to Embrace IPv6?

Aaron Wickware, 5/12/2026

The Short Answer

IPv4 isn’t dying anytime soon. IPv6 isn’t optional anymore either. Both of those things are true at the same time, and understanding why is more useful than picking a side in what’s become a tired industry argument.

IPv4 Ran Out Years Ago — And Kept Running Anyway

IPv4 gives the internet about 4.3 billion possible addresses. That sounded infinite in 1981. It doesn’t sound infinite when you’ve got billions of phones, laptops, IoT sensors, cloud instances, and servers all needing one. The regional registries have been out of fresh IPv4 allocations for over a decade now.

And yet IPv4 still carries somewhere in the range of 55-70% of global internet traffic today. Fortune 500 companies overwhelmingly run primary infrastructure on it. The reason isn’t stubbornness — it’s NAT. Network Address Translation let the internet keep growing on a fixed pool of addresses by letting thousands of devices share a small number of public IPs. It’s an ugly workaround by design standards, but it’s an effective one, and it bought IPv4 an extra twenty years of life nobody expected it to get.

That’s also exactly why there’s no hard shutoff date for IPv4. There’s no single moment where it stops working. Networks migrate when the cost of extending IPv4 finally exceeds the cost of adopting IPv6 — and for a lot of organizations, that day keeps getting pushed back.

So Where Does IPv6 Actually Stand?

Global IPv6 adoption sits in the mid-to-high 40% range as of 2026, and it’s been climbing steadily for years. But that headline number hides a massive gap depending on who you are:

– Mobile carriers: roughly 70-90% IPv6-capable — carriers had the strongest incentive to escape IPv4 scarcity early, since every new phone needs an address.

– Hyperscalers (AWS, Google, etc.): around 80% IPv6-enabled on public-facing infrastructure.

– Enterprise networks: roughly 30-32%.

– Small and mid-size businesses: around 17%.

In other words: the largest, best-resourced players moved first. The businesses in the 50-200 employee range — the ones without a dedicated network engineering team — are the ones still sitting almost entirely on IPv4, often without realizing it.

Most of the internet today runs dual-stack: both protocols active side by side. Pure IPv6-only deployments are still rare outside specific mobile and data-center environments. That dual reality — not a clean cutover — is the actual shape of this transition, and it’s likely to stay that way for a long time.

Why “Just Stay on IPv4” Isn’t a Free Ride

Here’s the part that doesn’t get said enough: staying IPv4-only isn’t neutral. It has a cost; it’s just a quieter one.

IPv4 addresses are now a scarce, tradeable asset. Because the registries are out of fresh allocations, address blocks now trade like commercial real estate. Growing your IPv4 footprint — more addresses for more servers, more customers, more services — increasingly means leasing or buying addresses on a secondary market instead of simply requesting them.

NAT adds complexity and fragility at scale. Every layer of NAT is another thing that can break, another source of latency, another obstacle for peer-to-peer connections and certain VoIP or real-time traffic. It works, but it’s a workaround, not an architecture.

IPv6 removes an entire class of problems by design. No mandatory NAT. Built-in address auto-configuration. A vastly larger address space that makes clean per-customer or per-device allocation trivial instead of a constant balancing act. For an ISP or managed service provider like Bullroar, this isn’t theoretical — it’s the difference between hand-rationing a shrinking IPv4 pool and handing out clean, purpose-built /48 allocations without a second thought.

Where IPv4 Genuinely Isn’t Going Anywhere

To be fair to IPv4: there are entire categories of infrastructure where it remains the more reliable operational choice today, and will for a while. Email deliverability still leans heavily on IPv4-based sender reputation systems. Plenty of legacy applications, payment processing systems, and specialized industrial or offshore equipment simply were never built with IPv6 in mind and won’t be retrofitted soon. Ripping that infrastructure out to “go IPv6” for its own sake is a solution in search of a problem.

The Right Question Isn’t “IPv4 or IPv6”

It’s dual-stack, deployed deliberately. The businesses handling this well aren’t the ones who rushed to flip everything to IPv6 to look forward-thinking, and they’re not the ones ignoring it either. They’re the ones who enabled IPv6 on public-facing infrastructure, watched how traffic actually split between the two protocols, and made decisions based on what they observed — not what a blog post (including this one) told them to believe.

For most SMBs, that looks like:

1. Confirm what your upstream ISP actually supports. You can’t run dual-stack if your provider only hands you IPv4.

2. Enable IPv6 on public-facing services first — websites, mail servers, VPN endpoints — where the operational risk of a misconfiguration is lowest, and the visibility into what’s actually happening is highest.

3. Don’t force it onto legacy internal systems that have no real reason to change and no vendor support for it.

4. Get your addressing plan right before you need it, not while you’re scrambling to onboard a customer or spin up new infrastructure under pressure.

The Real Risk Isn’t IPv6. It’s Not Having a Plan.

IPv4 will keep working for a long time. Nobody’s turning it off. But the businesses that treat IPv6 as “someday, not now” tend to be the same ones scrambling later — paying inflated prices for IPv4 space on the secondary market, or discovering during a growth spurt that their addressing architecture was never built to scale in the first place.

You don’t need to migrate everything tomorrow. You do need to know where you actually stand, and have a real plan for the parts of your network that will need it.

Bullroar Telecom operates dual-stack infrastructure across our network and manages IPv6 addressing at scale for our business customers. If you’re not sure where your organization actually stands on IPv6 readiness, that’s a conversation worth having before it becomes urgent.

Why SSL-VPN Is Fundamentally Weak (It's Not Any One Vendor's Problem) — and Why ZTNA Is the Future

Aaron Wickware, 5/5/2026

If you’ve followed cybersecurity news over the past few years, you’ve probably noticed a pattern: SSL-VPN vulnerabilities keep making headlines, and it’s not just one vendor. Nearly every major SSL-VPN product on the market has had serious, actively-exploited vulnerabilities disclosed at some point. This isn’t a coincidence, and it isn’t really about any one company’s code quality. It’s a structural problem with the SSL-VPN model itself.

The Core Design Flaw

An SSL-VPN’s entire job is to sit on the public internet, accept connections from anyone who reaches it, and decide whether to let them in. That means the VPN appliance itself is, by definition, an internet-facing target running complex, security-critical code — and it typically gets network-level access once a connection is authenticated. Attackers don’t need to compromise a user’s laptop or steal their credentials through phishing. They just need to find a flaw in the appliance itself, because that appliance is sitting there, reachable by anyone, all the time.

This is why SSL-VPN vulnerabilities are so consistently valuable to attackers, including nation-state groups: a single unpatched flaw in the appliance can grant access to an entire network, bypassing every other control behind it. And because these appliances are complex pieces of software handling authentication, session management, and cryptography all in one place, they’ve proven to be a rich target for vulnerability research — by defenders and attackers alike.

Why “Once You’re In, You’re In” Is the Bigger Problem

Even setting aside vulnerabilities in the appliance itself, traditional VPN access has a design assumption baked in from the 1990s: once a connection is authenticated, the user is treated as “inside” the network and typically has broad access to whatever that network segment can reach. A compromised laptop, a stolen credential, or a malicious insider connecting over VPN doesn’t just get access to the one application they need — they often get a foothold across a much wider swath of the network than the job actually requires.

This is the same “flat network” problem that’s driven ransomware from a single infected endpoint into a full-blown, company-wide incident again and again. VPN access wasn’t built with the assumption that the network itself needs to be defended from something already inside it.

What ZTNA Does Differently

Zero Trust Network Access flips the model. Instead of granting broad network access after a single authentication event, ZTNA verifies identity, device posture, and context continuously and grants access to individual applications — not the network as a whole.

No broad network exposure. A user connecting through ZTNA to reach a specific application never gets placed “on the network” the way VPN access does. They get a direct, brokered connection to that one application. If their credentials are compromised, the blast radius is that one application, not the entire network segment.

Nothing internet-facing to attack. ZTNA architectures typically don’t expose an internet-facing appliance the way SSL-VPN does. Connections are brokered outbound from inside the network to a cloud-based control plane, meaning there’s no equivalent to “scan the internet for vulnerable VPN appliances” — because there’s no listening appliance to find.

Continuous verification, not one-time login. ZTNA doesn’t treat authentication as a single event that grants standing access. Access decisions factor in device health, location, and behavior continuously, so a session that starts legitimately but starts behaving suspiciously can be cut off mid-session, not just blocked at login.

Granular, least-privilege access by default. Instead of “connected to the network,” users get “connected to exactly the applications their role requires” — which is a much smaller, much more defensible target than a full network segment.

Why This Matters More Than Ever

Remote and hybrid work made VPN the default way businesses handled off-site access, but the threat landscape that made VPN reasonable in 2015 isn’t the one we’re in now. Attackers actively scan the internet for exposed VPN appliances specifically because they know how valuable a single exploit can be. Every headline about a new SSL-VPN zero-day is really the same story repeating: an internet-facing appliance with broad network access got compromised, and the damage wasn’t contained to one user or one application — it spread.

The Bottom Line

This isn’t a weakness unique to any single vendor — it’s an industry-wide pattern rooted in how SSL-VPN was designed to work in the first place: an internet-facing appliance granting broad network access after a single login. ZTNA addresses both problems at the architectural level, not just with better patching. For businesses evaluating remote access strategy, the question isn’t really “which VPN vendor is safest” anymore — it’s whether VPN is still the right model at all.

Evaluating your current remote access architecture against a ZTNA model is part of what we look at in every Bullroar Cyber Threat Assessment Program engagement — no cost, no obligation, just a clear picture of where the exposure actually is.

Bullroar Telecom is a managed network security and engineering company based in Covington, Louisiana, with additional infrastructure in Baton Rouge and Fremont, CA, and a Tampa site coming online in Q4 2026. Learn more at www.bullroartel.com.

The Importance of Good Password Hygiene (Yes, Still)

Aaron Wickware, 4/28/2026

With all the talk of FIDO2, passkeys, and zero trust architecture, it’s tempting to think passwords are a solved problem — or an obsolete one. They’re neither. Most businesses are still running on passwords for the majority of their systems today, and password-related weaknesses remain one of the most common entry points attackers use. Until the passwordless future actually arrives everywhere, password hygiene is still doing a lot of the heavy lifting for your security posture.

Why This Still Matters

As we covered in our post on identity as the foundation of access, every security control downstream depends on knowing who’s actually authenticating. A weak or reused password undermines that foundation before anything else even gets a chance to work. It doesn’t matter how well-configured your firewall is if an attacker simply logs in with a valid, stolen password.

The Habits That Actually Cause Breaches

Password reuse across accounts. This is, by a wide margin, the single most damaging habit. When one service gets breached — and services get breached constantly, often ones you’ve never heard of — every account sharing that same password is now exposed too. Attackers run these breached credential lists against banking sites, email providers, and business logins automatically, in bulk, within hours of a new breach dump surfacing. This is called credential stuffing, and it works precisely because reuse is so common.

Weak, predictable passwords. Anything based on a name, a birthday, a season and year, or a keyboard pattern gets cracked in seconds by modern password-cracking tools, which can test billions of guesses per second against a stolen password hash.

Passwords shared over insecure channels. A password sent over email, Slack, or a text message sits there indefinitely, readable by anyone with access to that mailbox or chat history — including, eventually, an attacker who compromises the account much later.

Never rotating credentials for shared or service accounts. Personal password rotation on a fixed schedule is largely outdated advice now (more on that below), but shared logins, service accounts, and vendor credentials that never change are a different story — they accumulate risk every year nobody touches them.

Writing passwords down insecurely. The sticky note under the keyboard is a cliché because it’s still genuinely common, and it defeats the purpose of a strong password entirely if anyone walking by the desk can read it.

What Modern Guidance Actually Recommends

Password guidance has shifted meaningfully in recent years, and some of the old advice is now considered counterproductive:

Length over complexity. A long passphrase like several unrelated words strung together is both easier to remember and dramatically harder to crack than a short, complex string like `P@ssw0rd1!` — which looks strong but follows a predictable pattern attackers’ tools already account for.

Stop forcing frequent rotation. Forcing users to change passwords every 30 or 90 days, without a specific reason to believe a password was compromised, is now widely considered bad practice. It reliably pushes people toward small, predictable variations (`Summer2024!` becomes `Summer2025!`) that are barely different from the last password and just as easy to guess if the pattern is known.

Use a password manager, not memory. The realistic alternative to reuse isn’t “remember more unique passwords” — it’s not needing to remember them at all. A password manager generates and stores a genuinely unique, random password for every account, and is one of the single highest-leverage tools an individual or business can adopt.

Check for exposure, don’t just guess. Services exist specifically to check whether a given password or email address has appeared in a known breach. Building a habit of checking (and immediately changing anything flagged) closes the gap between a breach happening somewhere else and it actually being used against you.

Passwords are a bridge, not the destination. As covered in our earlier post on MFA and FIDO2, the real goal is moving critical accounts toward passwordless authentication entirely. Until every system supports that, good password hygiene is what closes the gap on everything still relying on a password as the first line of defense.

What This Looks Like for a Business, Not Just an Individual

A company-wide password manager, not individual choice. Leaving password management up to individual habits guarantees inconsistency. Deploying a business password manager across the organization — with shared vaults for team credentials where needed — removes the guesswork and gives IT actual visibility into weak or reused passwords across the company.

Breach monitoring at the domain level. Services exist that monitor whether any company email address shows up in a new breach dump, so IT can force a reset on affected accounts before an attacker gets there first, rather than finding out after the fact.

Clear policy on shared and service accounts. Every shared login and every service account should have an owner, a documented purpose, and a real rotation and review schedule — these are exactly the credentials that tend to be forgotten and never touched for years.

MFA as the real safety net. Good password hygiene reduces how often a password alone is enough to get an attacker in. It shouldn’t be the only thing standing between a stolen password and a full account takeover — which is exactly what MFA, and ideally FIDO2, is there to catch.

The Bottom Line

Passwords aren’t going away as fast as the security industry sometimes likes to suggest, and in the meantime, they remain one of the most common and most preventable ways attackers get in. Length, uniqueness, a password manager, and breach monitoring do more to close that gap than any amount of complexity-rule enforcement ever did — and none of it requires new hardware or a steep learning curve to put in place.

Reviewing how credentials are managed across your business — and where password practices are quietly creating risk — is part of every Bullroar Cyber Threat Assessment Program engagement.

It's All About Identity: Who You Are Is the Source of All Access

Aaron Wickware, 4/21/2026

Every security control we’ve written about — MFA, FIDO2, ZTNA, DLP — eventually comes back to the same single question: who is actually on the other end of this connection? Firewalls, encryption, and endpoint tools all matter, but they all sit downstream of one thing. If identity is wrong, everything built on top of it is wrong too. Identity isn’t one layer of security among many. It’s the foundation everything else stands on.

Why Identity Is the Real Perimeter

For most of the internet’s history, security was built around a network perimeter: a firewall separating “trusted inside” from “untrusted outside,” with the assumption that anything past the firewall was, by default, safe. Cloud applications, remote work, and mobile devices quietly dissolved that boundary years ago. There often isn’t a single network perimeter left to defend — data lives in Microsoft 365, in cloud-hosted applications, on personal devices, accessed from home, from a coffee shop, from a job site.

What’s left when the network perimeter disappears is identity. The question stops being “are you inside our building” and becomes “can you prove you’re who you say you are, from a device we trust, doing something consistent with your role.” That’s not a network question anymore. It’s an identity question.

What Happens When Identity Fails

Almost every major breach category we’ve covered in this series traces back to an identity failure somewhere in the chain:

Stolen or reused credentials. A password breached at one service and reused at another gives an attacker a valid identity to walk in with — no exploit required, because the system correctly believes it’s talking to the real user.

Phished MFA approvals. As covered in our post on MFA weaknesses, push-bombing and real-time phishing relay attacks don’t break the technology — they trick a real identity into approving something it shouldn’t. The system worked exactly as designed and still let the wrong person in.

Over-permissioned accounts. An account that’s correctly identified but grossly over-privileged — a marketing employee with domain admin rights left over from years ago, a service account nobody remembers creating — turns a minor compromise into a major one, because identity determined access far beyond what the role actually needed.

VPN’s flat-network problem. As covered in our post on SSL-VPN and ZTNA, traditional remote access treats a single authentication event as a blank check for broad network access. That’s identity being used correctly at the front door and then ignored for everything that happens after.

In every one of these cases, the technical control wasn’t necessarily broken. The identity behind it was compromised, misused, or given more trust than it should have had.

What “Doing Identity Right” Actually Looks Like

Strong authentication as the baseline. This is where FIDO2/passkeys matter — not as a nice-to-have, but because weak authentication methods are the easiest way for an attacker to obtain a valid identity in the first place.

Least-privilege access, tied to role, not tenure. Access should map to what a person’s current job actually requires, not what accumulated over years of role changes and forgotten permissions. Every excess permission is a wider blast radius if that identity is ever compromised.

Continuous verification, not one-time login. This is the core idea behind ZTNA: identity isn’t a single checkpoint at the door, it’s something re-evaluated continuously based on device health, location, and behavior. An identity that starts a session legitimately can still be cut off mid-session if something looks wrong.

Centralized identity management. When identity lives in one well-managed system — like Microsoft Entra ID — rather than scattered across dozens of app-specific logins, it becomes far easier to enforce consistent policy, spot anomalies, and revoke access immediately and completely when someone leaves the company or a credential is compromised.

Fast deprovisioning. A former employee’s account that’s still active weeks after they left isn’t a hypothetical — it’s one of the most common, entirely preventable sources of unauthorized access. Identity governance isn’t just about granting access correctly. It’s about removing it just as reliably.

Identity-aware policy at the network layer. This is where the pieces from earlier posts connect: Fortinet’s integration with Microsoft Entra ID means network and application access decisions can factor in who’s asking, not just where the traffic is coming from — the same identity, evaluated consistently, everywhere it touches the business.

The Bottom Line

Every layer of a security program — firewalls, VPN replacement, data loss prevention, encryption — exists to enforce a decision that was already made somewhere upstream: is this really who it claims to be, and should it have access to this. Get identity right, and every downstream control gets stronger. Get it wrong, and no amount of network security fully compensates, because the system will faithfully protect access for an identity that was never legitimate to begin with.

If there’s one question worth asking before any other security investment, it’s this one: do we actually know, with confidence, who has access to what across our business right now? That question is the starting point of every Bullroar Cyber Threat Assessment Program engagement.

Social Engineering: Your Users Are the First Line of Defense, Not the Last

Aaron Wickware, 4/14/2026

Businesses spend real money on firewalls, endpoint protection, email filtering, and network monitoring — and all of it matters. But the uncomfortable truth is that a huge share of successful breaches don’t route around those defenses at all. They walk right through the front door, because someone opened it for them. Social engineering doesn’t exploit a flaw in your network. It exploits trust, urgency, and habit — and no firewall rule fixes that.

What Social Engineering Actually Is

Social engineering is the practice of manipulating a person into doing something they wouldn’t otherwise do: clicking a link, approving an MFA prompt, transferring money, sharing a password, or letting someone into a building they shouldn’t be in. It works because it targets something technology can’t patch — normal, reasonable human behavior like wanting to be helpful, trusting a familiar name, or reacting quickly to something that feels urgent.

This is why social engineering shows up as the entry point in the overwhelming majority of breaches, even at organizations with substantial security budgets. It’s simply more efficient for an attacker to convince one person to hand over access than to find and exploit a technical vulnerability.

The Common Forms It Takes

Phishing. Still the most common vector by far — an email designed to look like it’s from a trusted source (a vendor, a bank, IT support, a coworker) that pushes the recipient toward clicking a link, opening an attachment, or entering credentials on a fake page.

Spear phishing and business email compromise. A more targeted version, often using real names, real project details, or a spoofed executive’s identity to request a wire transfer, gift card purchase, or sensitive file — built specifically for one person or one company rather than blasted out broadly.

Vishing (voice phishing). A phone call impersonating IT support, a vendor, or even a company executive, asking for a password reset, a code from an MFA prompt, or remote access “to fix an urgent issue.”

Pretexting. An attacker builds a plausible cover story — a new vendor, an auditor, a job candidate — to get information or access that seems reasonable to hand over in the moment.

Physical social engineering (tailgating). Someone in a delivery uniform or carrying a box, walking in right behind an employee who holds the door — no badge, no password, no technical exploit needed at all.

MFA fatigue and push bombing. Covered in more detail in an earlier post, but worth repeating here: this is social engineering aimed squarely at exhausting a user into approving something they shouldn’t.

Why “Just Train Them Once” Doesn’t Work

A lot of businesses treat security awareness as a once-a-year checkbox: a video, a quiz, done. The problem is that social engineering tactics evolve constantly, and a single annual training session fades from memory long before it’s actually needed in the moment of a real attack. Effective awareness isn’t a one-time event — it’s an ongoing habit built through regular, low-friction reinforcement: periodic phishing simulations, short refreshers, and a culture where reporting a suspicious email is easy and encouraged, not something people avoid out of embarrassment.

Turning Users Into a Real First Line of Defense

Make reporting effortless. If flagging a suspicious email takes more than a couple of clicks, most employees won’t bother. A simple “report phishing” button integrated into the email client removes the friction and turns every employee into an early-warning sensor for the whole company.

Run realistic phishing simulations regularly. Not to catch people out and shame them, but to build the reflex of pausing before clicking. Employees who’ve seen a realistic simulated phishing attempt are measurably better at spotting the real thing later.

Normalize verification, especially for money and access requests. Any request involving a wire transfer, gift cards, credential resets, or unusual access should have a built-in verification step — a callback to a known number, a second approver — regardless of how urgent or how senior the requester appears to be. This single habit stops the majority of business email compromise attempts cold.

Remove the shame from getting it wrong. The employee who clicked a phishing link and immediately reported it is a security asset. The employee who clicked, panicked, and said nothing for three days is how a minor incident becomes a major one. A culture where people report mistakes quickly, without fear of blame, is one of the single highest-leverage security investments a business can make

Pair awareness with technical guardrails. User training reduces how often someone falls for an attack — it doesn’t reduce it to zero, and it shouldn’t have to. Email filtering, MFA (ideally FIDO2-based, as covered in an earlier post), and least-privilege access limit the damage on the occasions training doesn’t catch it.

The Bottom Line

Every technical control your business invests in exists to catch what gets past the first line of defense — and that first line is your people. Firewalls don’t get phished. Employees do. Treating security awareness as an ongoing habit rather than an annual formality, and building a culture where reporting is fast and blame-free, does more to stop real-world breaches than almost any single piece of hardware you can buy.

Assessing how your team currently handles phishing and social engineering attempts — and where the gaps actually are — is part of every Bullroar Cyber Threat Assessment Program engagement.

The AI Arms Race: Why Attackers Are Winning the Speed War

Aaron Wickware, 4/7/2026

The AI Arms Race: Why Attackers Are Winning the Speed War

Every security vendor is talking about “AI-powered protection” right now, and most of it is real — machine learning genuinely does help detect anomalies faster than a human analyst staring at logs ever could. But there’s an uncomfortable asymmetry nobody likes to say out loud: attackers get to use AI too, and right now, they’re using it to move faster than most defensive AI can keep up with.

Why Attackers Have the Easier Job

Defensive AI has to be right almost all the time. It has to tell the difference between a legitimate software update and malware, a normal login from a traveling employee and a stolen credential, an unusual-but-fine business process and a data exfiltration attempt — all while generating as few false alarms as possible, because a security team that gets flooded with false positives starts ignoring alerts altogether.

Offensive AI doesn’t have that constraint. An attacker only needs one success. They can generate a thousand phishing variations, throw them all at a target list, and only care about the ones that get through. The math favors the attacker by default — they’re playing a volume game with no penalty for the misses, while defenders are playing a precision game where a single miss can be the whole incident.

What AI-Accelerated Attacks Actually Look Like Right Now

Phishing that doesn’t read like phishing anymore. The broken English and generic “Dear Customer” phishing emails of a few years ago are increasingly a thing of the past. Large language models let attackers generate fluent, contextually appropriate emails at scale — and with enough scraped LinkedIn data or a breached vendor list, those emails can reference real names, real projects, and real business relationships convincingly enough to fool a busy employee.

Voice cloning for business email compromise. A short public sample of someone’s voice — a webinar, a podcast appearance, a company video — is now enough to generate a convincing synthetic voice call. Combined with a spoofed caller ID and a plausible urgent request, this has already been used in real wire fraud incidents where an employee received what sounded exactly like a call from their CEO.

Automated vulnerability discovery. AI tools can scan code and network configurations for exploitable weaknesses far faster than manual research, compressing what used to take skilled attackers days or weeks into hours. The gap between a vulnerability being disclosed and it being actively exploited in the wild keeps shrinking as a result.

Malware that adapts on the fly. Rather than shipping one static piece of malware that a signature-based antivirus can eventually recognize, AI-assisted tooling lets attackers generate constantly mutating variants, making traditional signature detection meaningfully less effective than it was even a few years ago.

Faster, more convincing reconnaissance. AI tools can process a target’s public digital footprint — social media, press releases, job postings, vendor relationships — and assemble a detailed target profile in minutes, work that used to require a human analyst hours of manual digging.

Why Defensive AI Genuinely Struggles to Keep Pace

Defensive AI models are typically trained on historical attack patterns. That works well against known techniques, but AI-generated attacks are specifically good at producing novel-looking variations that don’t match a known signature or pattern closely enough to trigger detection — by design, not by accident.

There’s also a resource asymmetry: a single attacker with access to commodity AI tools can generate an enormous volume of attack attempts cheaply. Defensive systems have to inspect, evaluate, and make a correct call on every single one of those attempts, in real time, without slowing down legitimate business activity. Attackers get to fail cheaply and repeatedly. Defenders don’t get that luxury.

So What Actually Helps?

This isn’t a reason to give up on AI-assisted defense — it’s a reason to be honest about what it can and can’t do on its own.

Layered detection, not a single AI tool. No single defensive product is going to catch everything. Behavioral analysis, network-level monitoring, endpoint detection, and email filtering working together catch far more than any one layer alone, precisely because an attack that slips past one layer often trips a different one.

Faster human review of what AI flags. AI is genuinely good at surfacing anomalies faster than a human could find them manually. It’s not yet reliably good at making the final judgment call on ambiguous cases. The businesses that fare best pair AI-driven detection with fast, well-trained human review of what gets flagged — not AI running fully unsupervised.

Reducing the attack surface that AI-driven attacks depend on. A lot of what makes AI-accelerated attacks effective — phishing that gets through, credentials that get reused, VPN appliances sitting exposed on the internet — are the same fundamentals covered in a solid security program regardless of how sophisticated the attack gets. Fewer entry points mean fewer places an AI-generated attack can even land.

Assume the human layer is the real target. Since AI-driven attacks are increasingly optimized to fool people rather than systems — convincing phishing, cloned voices, well-researched pretexting — ongoing user awareness training matters more, not less, in an AI-accelerated threat landscape.

The Bottom Line

AI hasn’t broken cybersecurity, but it has changed the pace of the fight, and right now attackers are better positioned to exploit that speed than most defenders are to match it. The businesses that hold up aren’t the ones chasing the newest AI-branded security product — they’re the ones with layered defenses, monitored networks, and a realistic understanding of where the human layer is exposed.

Evaluating where your business is exposed to these faster, more convincing attack techniques is part of every Bullroar Cyber Threat Assessment Program engagement — no cost, no obligation, just a clear picture of where the real gaps are.