The Chiton Guard EBS Security Maturity Model

This is the second post in the Chiton Guard blog series. The first post explained why I came out of retirement to work on EBS security and what I founded Chiton Guard to do. This post lays out the EBS security maturity model I’ll use for the rest of the series.

EBS security is too often discussed as a checklist. Are the latest patches applied? Is TLS configured? Are the right profile options set? Are logs retained? Are customizations reviewed?

Those questions matter, but treated individually they miss the larger problem. Oracle E-Business Suite security is not one control, one product, one patch, or one scan. It is a progression. Each layer depends on the one before it. A team that has not retained the right logs cannot confidently determine what is actually being used. A team that has not reconciled menus, responsibilities, functions, and Allowed Resources cannot safely tighten enforcement. A team that has not inventoried custom code cannot know whether Oracle’s seeded controls cover the application it is actually running.

The framework I’ll use for this series is the Chiton Guard EBS Security Maturity Model. The goal is to give EBS owners, Apps DBAs, security teams, auditors, and business stakeholders a practical way to think about security posture, remediation priorities, and the evidence needed to make defensible decisions.

The common thread is evidence: not “we think this is protected,” but “we can show what is exposed, who can reach it, whether it is used, and whether the intended controls are actually active.”

Level 1: Basic platform hygiene

At the foundation is basic platform hygiene: patching, TLS, HTTP headers, database account controls, guest access settings, diagnostics, and baseline request filtering.

This is the layer most teams already recognize. It includes Critical Patch Update cadence, secure transport configuration, session cookie protections, database account hygiene, password and profile policies, diagnostic restrictions, and basic web-tier protections. These controls are necessary, but they are only the starting point.

A team can be current on patches and still have unnecessary exposure. A team can have TLS configured and still have broadly reachable diagnostic pages. A team can have baseline filtering enabled and still have custom endpoints outside the security model. Level 1 matters because the foundation has to be solid, but EBS security does not end there.

Level 2: Evidence and visibility

The next layer is evidence and visibility. Before an organization can safely tighten controls, it needs to know what the environment is actually doing.

Level 1 is foundational, but much of it is reactive by nature. Critical Patch Updates fix vulnerabilities Oracle has already found and disclosed, on Oracle’s schedule, not yours. Baseline hardening closes known configuration gaps. Default-account cleanup, TLS hardening, diagnostic restrictions, and request filtering are all necessary, but they mostly address risks that are already understood.

Evidence and visibility are what let a team start to become proactive. Logs, configuration history, and usage signals let you understand real behavior before an incident, an audit, or a patch cycle forces the question. They help you find what is active, what is dormant, what is drifting, and what may be exposed in ways the standard checklist does not reveal.

That means retaining the logs and configuration history needed to understand real behavior over time: OHS access logs, error logs, FND application logs, security-relevant configuration, and other signals that show which resources are active, which paths are used, which endpoints appear dormant, and where suspicious activity or regressions may be occurring.

Part of building that evidence is learning to tell genuine user activity apart from scanning traffic. Vulnerability scanners, security tooling, and hostile reconnaissance all generate requests that look like activity in a raw log but are not evidence that a resource is actually in use by the business. Treating scan traffic as real usage produces a distorted picture of the environment, and it becomes a recurring obstacle later, when a team hesitates to lock down an endpoint because “something is still hitting it.”

Without evidence, lockdown becomes guesswork. Teams either leave risky surfaces exposed because they are afraid of breaking the business, or they tighten controls without understanding the impact. Level 2 is about creating the visibility needed to make security decisions with confidence.

Level 3: Security model understood and reconciled

Once visibility exists, the next step is to understand and reconcile the EBS security model.

This means looking at Allowed Resources, menus, responsibilities, functions, grants, forwards, redirects, and customizations as related parts of the same system. A URL may exist on the file system, appear in the Allowed Resources registry, be reachable through a menu path, be reachable only through a forward chain, or be exposed in production traffic. Those are not the same thing.

Custom code belongs in this reconciliation, not off to the side. Almost every EBS customer has customizations, and some have decades of them: custom JSPs, OA Framework pages, local extensions, third-party integrations, modified flows, and custom responsibilities. The question at Level 3 is whether that custom code is mapped into the same picture as seeded code. Does it register itself in Allowed Resources the way Oracle’s own code does? Is it reachable through the menu and responsibility structure, or only through paths nobody has documented? A customization that made sense years ago may now be reachable through an unexpected path, or missing the authorization checks expected of the code around it. Custom code is often where EBS risk becomes customer-specific, and reconciliation is where that becomes visible.

Many environments have drift between what the configuration suggests, what the registry says, what users can actually reach, and what the application is serving. Level 3 is about finding and understanding those gaps before enforcement is tightened.

Level 4: Enforcement activated and tightened

Only after the model is understood does it make sense to activate and tighten enforcement.

This includes Allowed Resources Authorization, Allowed Forwards, function-level controls, resource restrictions, guest-access controls, and other enforcement mechanisms that determine what the application will actually allow at runtime. It applies to custom code the same way it applies to seeded code: the enforcement layer should not stop at the edge of Oracle’s own application.

This is where proactive versus reactive stops being an abstract distinction and becomes a decision. Tightening enforcement because the evidence supports it, before anything has gone wrong, is proactive. Tightening it only after an incident, an audit finding, or a disclosed CVE is reactive, and it means the exposure was live for however long it took to notice. The sequencing of this model exists to make the proactive path practical: turning on enforcement before understanding real application behavior can break legitimate business flows, while leaving enforcement disabled indefinitely because the system is complex can leave important attack surfaces exposed.

The scanning-traffic problem from Level 2 tends to surface here as an objection. If traffic to a dormant endpoint has already been identified as scan activity rather than genuine business use, it is not a reason to leave the endpoint open. Confusing the two is one of the more common ways teams talk themselves out of tightening things that are actually safe to tighten. Level 4 is about moving from configured intent to active protection, carefully and with evidence.

Level 5: Exposure and access validated

At this point, the question becomes empirical: what is actually exposed?

Not just what the configuration says. Not just what the registry implies. Not just what a generic scanner sees. What does the application actually serve to anonymous users, guest users, self-service users, ordinary authenticated users, and privileged users?

Level 5 is about validating real exposure from different actor perspectives and comparing that behavior against the intended security model. This is where assumptions are tested. Endpoints that appear protected may respond in unexpected ways. Resources that seem dormant may still receive production traffic. Customizations that appear internal may be reachable through broader paths than expected.

A mature security program should be able to explain not only what exists, but who can reach it and whether that access is justified.

Level 6: Vulnerabilities identified and mitigated

After exposure has been validated, the next level is finding actual vulnerabilities in whatever remains exposed, and closing or mitigating them.

By this point the model has been reconciled, enforcement has been tightened, and real exposure has been tested from different actor perspectives. What remains is a smaller and better-understood set of code to examine: custom code, Oracle-seeded code, and third-party or integration code alike. Static and dynamic analysis, targeted code review, and dependency checks all apply here, and they apply regardless of who wrote the code. A vulnerability in a custom extension is not inherently more or less urgent than one in a seeded page just because of where it originated.

Mitigation does not always mean an immediate code fix. Sometimes it does: the code is owned internally, the fix is well understood, and it ships. Other times a code-level fix is not immediately available, whether because the code is vendor-owned, the fix carries regression risk, or the timeline does not allow it. In those cases the mitigation may be a compensating control: a WAF or ModSecurity rule, an OHS restriction, a reverse-proxy control, or another virtual patch that reduces exposure until a code-level fix can be delivered. Level 6 is about having both paths available and knowing which one a given vulnerability calls for.

Level 7: Attack surface minimized and sustained

The final level is sustained attack-surface reduction.

Unused endpoints should be removed or restricted. Dormant functionality should be reviewed. Broadly exposed resources should be justified or tightened. High-risk customizations should receive deeper review. WAF and ModSecurity rules should be calibrated to the actual application footprint. Security checks should become part of change management so the posture does not quietly regress after patches, clones, emergency fixes, or new customizations.

The goal is not a longer findings list. The goal is a smaller, better-understood, better-controlled attack surface that can be sustained over time.

How to use the model

The maturity model is not meant to be a certification scheme or a rigid scoring exercise. It is a practical way to ask better questions.

The model surfaces where the foundation is weak, where evidence is missing, and where the security model fails to match real behavior. It shows which enforcement features are configured but not active, which customizations sit outside the expected controls, which endpoints are actually exposed and to whom, and which risks should be fixed first.

Those answers are more useful than a generic statement that an environment is “secure” or “insecure.” Most EBS environments sit somewhere along this maturity curve, with strengths in some areas and gaps in others.

The purpose of the model is to help teams move forward in the right order: first establish the foundation, then build visibility, then reconcile the model (custom code included), then tighten enforcement, then validate exposure, then identify and mitigate remaining vulnerabilities, and finally sustain attack-surface reduction over time.

If you want a fast read on where your own environment stands at Levels 1 and 2, the free assessment is a good starting point. Levels 3 through 7 are where much of the deeper EBS-specific risk tends to hide, and where a more detailed assessment can help connect configuration, reachability, exposure, customizations, and remediation priorities.

What comes next

Generic tools can help. Generic web application firewalls and vulnerability scanners can provide important protections. But EBS has its own URL structures, parameter conventions, authorization model, navigation paths, function security, menu system, responsibilities, guest access patterns, resource-control infrastructure, forwards, redirects, and customization model. The next post starts where the practical work begins: why Oracle E-Business Suite is different from ordinary web applications, what generic security tools miss, and why EBS-specific evidence changes the way security teams should think about risk.

Understanding those differences is the foundation for the rest of the series.

---

Eric Bing is the founder and principal security architect at Chiton Guard. He spent 32 years working on Oracle E-Business Suite, including 12 years leading the EBS security and privacy team.