Ethos by Hoplite
The same working record, kept current as your systems change.
Keep the answer current as your systems change.
Ethos suits organizations whose systems, identities, and suppliers change often enough that a yearly snapshot goes stale. Whether it builds on earlier Hoplite work or starts fresh is decided with you.
Your environment changes faster than your test cycle
New applications, cloud accounts, acquisitions, vendors, and permission changes can open routes a past report never saw.
You want the context to carry over
Each new test should start from what is already known about your paths, fixes, and decisions, not from zero.
You want retests to be part of the plan
Confirmed paths, your fixes, and Hoplite's retests stay in one record, under terms agreed for your program.
How a program runs.
Each step has a clear owner. Software keeps the context current; Hoplite operators decide what to test and confirm it; your team owns the fix.
- Hoplite
Baseline
The program starts by establishing a baseline of the agreed scope. Where recent Hoplite testing already covers it, that work can serve as the baseline.
- Ethos
Maintained context
Ethos keeps what was learned about systems, identities, permissions, and earlier paths, and updates it as your environment changes. Paths it identifies here are modeled, not confirmed.
- Hoplite operator
Prioritized operator validation
Operators pick the modeled paths most likely to matter and test them under the agreed rules of engagement.
- Hoplite operator
Finding
When a path reproduces, it is reported as a confirmed finding with evidence and options for where to break it.
- Your team
Customer remediation
Your team chooses the break point and makes the change. Hoplite guides the decision when you want input.
- Hoplite operator
Hoplite retest
Hoplite retests the route within the retest entitlement in your program terms and records the result.
- Together
Review
We review what was confirmed, what changed, and what remains, and adjust scope, cadence, or triggers if needed.
A modeled path is a lead. A confirmed path is a finding.
We keep the two apart in every report, so your team spends its time on routes that have been shown to work.
Modeled path
A route Ethos identifies as possible from the context it holds. It guides where operators look. It is not reported as a finding.
Confirmed finding
A route a Hoplite operator has tested under the agreed rules and reproduced, with evidence for each step.
Retested
A confirmed route tested again after your team's change, under the retest terms of your program, with the result recorded.
What the record keeps.
An illustrative example of one path in an Ethos program. Step through it: real records follow the same stages, with your systems and evidence.
Path record: illustrative example
Not customer data. No live values.
Example route
- Entry pointInternet-facing remote access portalPossible, not a finding
- HopReused service account passwordPossible, not a finding
- HopGroup with broad file-share rightsPossible, not a finding
- ObjectiveFinance file serverPossible, not a finding
Modeled · Ethos
A possible route from the portal to the finance file server, identified from what is known about the systems, identities, and permissions in scope. It guides where operators look. It is not a finding.
- Modeled: possible, not a finding
- Confirmed by an operator, with evidence
- Where your team broke the route
A retest shows whether this specific route still works. It is not a guarantee that no other route exists.
Agreed for each program, before it starts.
- Scope
- Which systems, identities, applications, and environments are included, and what is off limits.
- Cadence
- How often operators return to validate prioritized paths.
- Triggers
- Which changes in your environment prompt a closer look between scheduled work.
- Retest entitlement
- Which fixes Hoplite retests, and how, within the program.
- Rules of engagement
- Testing windows, safety constraints, contacts, and escalation.
What Ethos does not promise
- Ethos does not see everything. It works within the agreed scope and the context available to it.
- Operators do not test around the clock. They validate prioritized paths on the agreed cadence and triggers.
- Hoplite does not make changes in your environment. Your team remediates; Hoplite guides and retests.
- A retest confirms whether a specific route still works. It is not a guarantee that no other route exists.
Questions we hear.
Do we need a penetration test before Ethos?
No. Every program starts from a baseline of the agreed scope, established at the start of the program. If recent Hoplite testing already covers that scope, that work can serve as the baseline. We decide this with you when we agree scope and cadence.
Is every modeled path tested by an operator?
No. Operators prioritize the modeled paths most likely to matter and test those under the agreed rules. Modeled paths that have not been tested are never reported as findings.
Who fixes what Ethos finds?
Your team does. Hoplite explains where a confirmed path can be broken, helps you weigh the options, and retests the route under your program's retest terms.
How often do operators test?
That depends on the cadence and triggers agreed for your program. We set them together at the start and revisit them at each review.
Talk through what an Ethos program would cover.
Bring your environment, what you have tested before, and what changes most often. We will sketch a scope, cadence, and triggers, or tell you if a bounded assessment fits the outcome better.