CANYO CANYO

BEHIND THE SCENES OF

CANYO CANYO

How CANYO
Actually Runs.

You trust us with your technology. Here's what happens behind our walls.

// WHY WE'RE SHOWING YOU THIS

You Shouldn't Have to Trust a Black Box

CANYO is a Tucson-based managed IT services provider. We manage technology, infrastructure, security, backups, and day-to-day IT operations for businesses that depend on their systems working reliably.

That creates an important responsibility. Clients trust us with access to their networks, devices, systems, credentials, backups, and business data. We don't think that trust should require a black box.

So we've decided to open the box. Not by publishing credentials, internal addresses, or operational secrets — those should remain private. Instead, we're willing to explain how CANYO itself is designed and operated, the principles behind those decisions, the technologies we use, and the controls we use to enforce them.

Because we believe a good MSP should be willing to show its work.

// NON-NEGOTIABLES

The Four Principles We Don't Compromise

01

Least Privilege

Access should provide only the permissions actually required to perform a job. If something doesn't need the ability to delete, it shouldn't have delete permission. If something doesn't need administrative access, it shouldn't have it. We apply this to credentials, backups, infrastructure, automation, and the systems we use to manage technology.

02

Defense in Depth

Important security boundaries shouldn't depend on a single control. We design multiple independent layers so that a failure of one control doesn't mean the next boundary disappears with it. Security shouldn't be one locked door — it should be multiple doors that don't all use the same key.

03

Verification Over Trust

We don't consider something secure simply because it was configured that way. We test. Security-relevant configurations are verified against controlled or disposable systems before we trust them with real client data. The question isn't "did we configure it correctly?" — it's "can we demonstrate that it actually behaves the way we intended?"

04

Isolation by Default

Systems should be separated unless there is a deliberate reason for them to communicate. We don't want security to depend on someone remembering not to cross a boundary. Where practical, the boundary should be enforced by the technology itself.

These aren't four ideas we put on a webpage. They're constraints we use when building and operating CANYO.

// DEFENSE IN DEPTH, IN PRACTICE

Our Layered Access Model

One of the clearest examples of how CANYO applies its security principles is the way we protect our own internal management tools. They are not exposed directly to the public internet. Access is intentionally layered, with multiple independent controls between an outside user and the actual application.

// THE ACCESS PATH

01

Tailscale

Private network access

Is this device authorized to participate in our private network?

02

Authentication Gateway

Username + password

Does the user have the correct username and password?

03

Second-Factor Verification

Independent second authentication factor

Can the user satisfy the second authentication factor?

04

Application Authentication

Separate application credentials

Does the user have the separate credentials required by the actual tool?

Four independent questions — and getting through one layer does not automatically get you through the next.

LAYER 1 — PRIVATE NETWORK ACCESS

Tailscale

The first boundary is the network itself. We use Tailscale to create a private, encrypted mesh network between authorized devices and internal resources. Our internal management tools are not sitting on the public internet waiting for someone to find a login page. A device must first be authorized to participate in our Tailscale network before it can even attempt to reach those services. An unauthorized party would first have to somehow gain access to an authorized device or otherwise satisfy the controls governing our private network — otherwise, the internal application simply isn't reachable.

LAYER 2 — USERNAME + PASSWORD

Authentication Gateway

Assume, purely for the sake of explaining the architecture, that someone somehow makes it through the private network layer. They still haven't reached the application. The next boundary is a dedicated authentication gateway requiring a separate username and password. These credentials are not the same credentials used by the underlying application. Getting through the private network therefore does not automatically make someone an authenticated user.

LAYER 3 — SECOND FACTOR

Second-Factor Verification

Take the hypothetical one step further: suppose someone somehow obtains the correct gateway username and password. They're still not through. The next step requires an independent second factor of authentication. This creates another separate requirement before the protected application can be accessed — a compromised password alone is not intended to be sufficient.

LAYER 4 — SEPARATE CREDENTIALS

Application Authentication

Now suppose someone somehow makes it through every previous layer. They finally reach the actual internal application — and they're still not automatically logged in. The individual application maintains its own separate authentication, with credentials distinct from those used by the gateway. We deliberately don't identify which internal applications we run: the architecture is what matters, and publishing a target list would only hand out enumeration information.

// THE REASONING

Why We Built It This Way

Could we make this easier? Absolutely. We could expose an application directly to the internet. We could use a single authentication layer. We could reuse credentials. It would also be easier to operate. We deliberately chose otherwise.

The goal isn't to claim that any individual security layer is impossible to defeat. The goal is to make sure that defeating one layer does not automatically defeat the next. A person who somehow crosses the network boundary still encounters authentication. A person who somehow obtains a password still encounters two-factor authentication. A person who somehow crosses those controls still encounters the application's separate credentials.

The additional friction is intentional. Defense in depth means that one mistake, one compromised credential, or one failed control should not automatically become complete access.

// THE TOOLS

The Technologies Behind CANYO

Our stack explains what we use. Here's why each piece exists in this architecture.

Tailscale

The private mesh network connecting authorized devices to internal resources. Its role: keep internal services off the public internet and restrict network access to authorized devices.

NETWORK BOUNDARY

Authentication Gateway

A dedicated authentication layer in front of protected internal services. Its role: provide another independent boundary, including two-factor authentication, before any application can be reached.

AUTHENTICATION BOUNDARY

Application Authentication

The applications themselves maintain their own authentication. We don't treat the gateway as a replacement for application-level security — where practical, the application has its own separate credentials.

APPLICATION BOUNDARY

POLARIS

Our internal AI agent handles first-pass triage and continuous monitoring, surfacing patterns and low-risk conditions to our technicians. It doesn't replace human judgment — it gives our team the earliest possible signal so they can make the decision that matters.

TRIAGE + MONITORING

The products themselves aren't the security strategy. The architecture is. Together, they create multiple independent controls between an unauthorized party and the tools we use to operate CANYO.

Each tool has a specific job. More importantly, the tools are designed to work together.

OS

CanyoOS COMING SOON

CANYO's own vertically integrated RMM, custom-built in-house to unify management, visibility, security, and automation across every endpoint.
GZ

Guardz / SentinelOne

Threat detection

TS

Tailscale

Network control / containment

RS

Restic + Backblaze B2

Recovery

CA

CISO Assistant

Governance / evidence

SEE WHAT CANYO USES →

// BACKUPS

Backups: Designed to Resist the Worst Case

Backups are only useful if they survive the thing you're trying to recover from. That's why we don't treat backup security as simply "we have another copy of the files." We care about what an attacker — or a compromised machine — is actually capable of doing to that copy.

Data is encrypted before transmission. Files are encrypted on the client device before they ever leave it, so the backup destination isn't simply receiving a collection of readable client files.

The backup credential can't delete what it creates. The credential stored on a client device is intentionally limited: it can add new backup data, but it cannot delete existing backup data. If a client machine were compromised, the credentials available on that machine shouldn't automatically give an attacker the ability to erase the backup history they need to destroy. A separate credential exists for cleanup and administrative operations — and that credential does not live on the client device.

Least privilege isn't a statement here. It's a property of the credential itself.

// ISOLATION

Client Network Isolation Is Enforced Technically

We don't want network isolation to depend on a policy that says "CANYO won't let these systems communicate." We prefer the network itself to enforce the boundary. A client's devices are permitted to communicate according to the rules defined for that environment — and where communication isn't permitted, the network prevents it.

That's an important distinction. A policy depends on someone following the policy. A technical boundary doesn't care about someone's intentions.

That same principle extends to threat containment. When endpoint detection identifies malware on a managed device, the network itself responds: the device's connectivity is automatically restricted, preventing the threat from moving laterally into servers or other systems. The response doesn't wait for a human to notice — it happens because the architecture is built to enforce it.

It's the difference between saying "please don't open that door" — and building the door so you don't have access to it in the first place.

// HUMAN ACCOUNTABILITY

Some Things Should Still Require a Human

Automation is powerful. But automation shouldn't mean that every sensitive operation becomes possible without deliberate human involvement.

The provisioning of new infrastructure that touches our most sensitive master credential remains a deliberate human step. It isn't something we allow an unattended process to perform automatically — a real person has to trigger it intentionally when it's needed.

We deliberately accept that small amount of friction, because the alternative is allowing one more highly privileged operation to happen without human intent.

// WHERE THE LINE IS

What Automation Is Allowed to Do

"AI-assisted" and "automated" shouldn't be vague. These are the permission boundaries we operate under:

ACTION AUTOMATED? HUMAN APPROVAL?
Restart a failed serviceYesNo — pre-approved procedure
Install routine patchesYesNo — scheduled maintenance
Isolate an infected endpointYesNo — containment can't wait
Run approved remediation scriptsYesNo — tested and reversible
Disable a user accountNoYes — always
Modify firewall or network policyNoYes — always
Delete or alter dataNoYes — always
Change security policyNoYes — always
Restore from backupNoYes — verified and approved
Automated fix doesn't verify as successfulNoEscalates automatically

The pattern is deliberate: automation handles known, reversible, low-risk actions. Anything that changes access, data, or policy requires a human.

// CHANGE MANAGEMENT

Reversible-First Operations

Every change we make is designed to be safe and reversible. Before a significant change touches a real system, we ask: if this goes wrong, how do we undo it?

Major or risky changes are carefully vetted and never performed without explicit client approval. Security-relevant configurations are tested against disposable systems before they ever touch real client data. The goal isn't to avoid change — it's to make change safe enough that it becomes routine rather than risky.

A change that can't be undone isn't a change. It's a gamble.

// VERIFICATION

We Test the Isolation

A configuration isn't proof. A policy isn't proof. A checkbox isn't proof.

Behavior is proof.

When we introduce security-relevant infrastructure or configurations, we test the isolation and behavior against controlled, disposable systems before trusting those configurations with real client data. The goal is to discover mistakes while they're cheap and harmless to fix. We would much rather discover that an isolation boundary doesn't behave as expected in a throwaway environment than discover the same thing after a real client system is involved.

This is the same philosophy we apply throughout CANYO: Verification Over Assumption.

// WHEN SOMETHING GOES WRONG

How CANYO Responds to an Incident

Every incident follows the same disciplined sequence — no improvisation, no skipped steps. We apply the CANYO Operating Loop to incident response: it's the same eight-stage loop used everywhere else, just framed around what happens when something goes wrong.

01

Observe

Continuous monitoring reports what's actually happening — a stopped service, a failed backup, an unexpected change, or malware detected by endpoint protection.

02

Decide

The condition is measured against policy. Is this normal? Is it risky? Does it need action now or later?

03

Authorize

Anything consequential — isolation, data changes, policy changes — is gated by permission. Containment of malware is pre-authorized because waiting isn't safe; everything else waits for a human.

04

Preview

Before acting, we look at what the response will do: what systems it touches, what access it changes, what could go wrong.

05

Execute

The approved action runs — whether that's isolating an endpoint, restarting a service, or applying a reversible fix.

06

Verify

The fix is confirmed against the expected outcome — not assumed to have worked.

07

Record

What happened, what was done, and what the result was — logged permanently for the client and for CANYO's records.

08

Escalate

When something is ambiguous, unusual, or high-stakes, a human is brought in — sometimes before any action is taken.

What You're Told

You don't sit and wait for a status update. As soon as we have a real answer — not a guess, not a placeholder — we communicate it. For active incidents, that means an initial acknowledgment quickly, followed by a clear update once we've observed, decided, and verified what's actually going on. You get the facts we have, the action we're taking, and what we still need from you. No theater, no vague "we're looking into it" without a timeline.

// WATCH IT HAPPEN

A Generic Incident, Start to Finish

This is a simulated walkthrough of how CANYO handles a real event — no client data, just the process. Press play.

canyo / operations
PRESS PLAY TO WATCH AN INCIDENT RESOLVE ITSELF.
01 OBSERVE 02 DECIDE 03 AUTHORIZE 04 PREVIEW 05 EXECUTE 06 VERIFY 07 RECORD 08 ESCALATE
OPEN THE LIVE MACHINE →

// AN ILLUSTRATIVE SCENARIO

What Happens When
Ransomware Hits

The sequence above describes the discipline. This is what it looks like against the clock. This is an illustrative scenario, not a promised timeline — real incidents vary. What doesn't vary is the order of operations.

10:02 AM

Endpoint detects malicious activity

SentinelOne flags ransomware behavior on a managed workstation.

10:02 AM

Endpoint isolated

The device's network access is automatically restricted through Tailscale — lateral movement is cut off before a human even opens the alert.

10:04 AM

Incident investigated

A technician confirms the detection, scopes the blast radius, and checks whether any other system was touched.

10:17 AM

Threat removed

The malicious process and its persistence mechanisms are remediated using controlled procedures.

10:25 AM

Backup integrity checked

The most recent clean restore point is identified and backup data is verified readable.

10:41 AM

Required data restored

Affected files are recovered from the verified snapshot — not from the encrypted copies.

11:00 AM

Recovery verified

The workstation is confirmed clean, data is confirmed intact, and the incident is documented — what happened, what was done, what the result was.

Notice what didn't happen: nobody negotiated with an attacker, and nobody hoped the backup worked.

// THE CANYO APPROACH

Enforcement Over Promises

There is a common pattern in technology: "we have a policy for that." We prefer a different question: can the system enforce it?

THE PROMISE VERSION

  • "We have a policy that these networks don't communicate."
  • "We have a policy that backup credentials are protected."
  • "We have a policy that sensitive changes require approval."
  • "We have a policy that security boundaries are tested."

THE CANYO VERSION

  • The network itself prevents the communication.
  • The credential technically lacks deletion privileges.
  • The process requires deliberate human action.
  • The boundary is tested against disposable systems first.

This doesn't mean policies aren't important. It means important policies should be backed by technical controls whenever practical.

// THE DIFFERENCE

What Makes CANYO Different

We don't believe managed IT should depend on trust alone.

CANYO builds its operations around verification, restricted access, technical isolation, and deliberate change. When something matters, we look for ways to make the desired behavior enforceable rather than simply writing a policy and hoping someone follows it.

That's why we don't just ask: "Do we have a policy for this?" We ask: "Can the system enforce it?"

That distinction shapes how we approach security, backups, access, network design, infrastructure, and day-to-day IT operations.

We don't just manage technology. We engineer the environment around it.

// THE BUSINESS TRANSLATION

Why This Matters to Your Business

The point of all this technology isn't to impress another IT professional. It's to reduce two things for the people running a business.

Less Downtime

Technology should be predictable. Problems should be detected early, systems maintained deliberately, backups usable, and changes made with an understanding of how to reverse them. The goal isn't simply to respond when something breaks — it's to make serious problems less likely to happen in the first place.

Less Stress

Business owners shouldn't have to wonder whether everything is actually working, whether the backups are really there, who has access, or what happens if a computer fails or ransomware hits. Good IT should remove uncertainty rather than create more of it.

The technology is important. But the outcome we care about is a business that can operate without constantly worrying about its technology.

// TRANSPARENCY WITHOUT EXPOSURE

What We Keep Private

Transparency doesn't mean publishing an attack map. There is a meaningful difference between explaining architecture and exposing secrets.

WE'RE HAPPY TO EXPLAIN

  • Our security principles and access-control approach
  • How we think about isolation and backups
  • Why we use multiple security layers
  • How we verify important configurations
  • Why certain operations require human involvement
  • The technologies we use to implement these principles

WE DO NOT PUBLISH

  • Credentials, secrets, or keys
  • Internal addresses, hostnames, or ports
  • Authentication endpoints or configuration details
  • Internal application names or client infrastructure details
  • Anything that would unnecessarily increase our attack surface

Transparency means showing our reasoning, not handing out the keys.

// OPERATING PHILOSOPHY

We Don't Expect You to Take Our Word for It

That's the underlying idea behind everything CANYO does. We document. We verify. We isolate. We restrict access. We test. We make important boundaries technical where practical. And when something is important enough to require an exception, we want that exception to be deliberate rather than accidental.

Our clients don't need to understand every technical detail behind their environment. But they should be able to understand the philosophy behind the way we operate it.

// THE SHORT VERSION

If You Remember Nothing Else

01

Least Privilege

Give systems only the access they need.

02

Defense in Depth

Don't let one failed control become total access.

03

Verification Over Trust

Don't assume a security boundary works. Test it.

04

Isolation by Default

Don't rely on people to respect boundaries that technology can enforce.

We try to make the secure behavior the behavior the system permits.

That's how CANYO runs behind the scenes. That's also how we believe managed IT should be done.

// GET STARTED

Want IT That Works This Way for Your Business?

CANYO provides structured managed IT services for businesses in Tucson and across Southern Arizona. Monitoring, maintenance, support, backup and recovery, security, reporting, and ongoing management — handled as one managed system. Less downtime. Less uncertainty. Less IT to worry about.

Get a Free Assessment See What's Covered