Operating servers that accept external connections also requires care in handling their reports. Server or software faults, configuration changes or a possible compromise may prevent reports from adequately reflecting the actual state.

BASTION emphasizes verifying information from agents in the DMZ and limiting the scope of permitted actions. This article introduces that approach and the points to check during operation.

1. Treating reports as information to be verified #

Receiving a report from an agent does not necessarily mean its contents have been sufficiently verified. Checks appropriate to the operating environment are needed to assess whether the information can be used for decisions.

BASTION defines the roles of receiving reports and making defense decisions, with responses informed by the results of verification.

2. Limiting the scope of actions #

The functions an agent can use and the targets it can act on are limited according to the deployment environment’s requirements. Necessary roles and permissions are defined, and their effects on existing operations are checked.

Restricting permissions is one protective measure. It is not assumed to prevent every consequence of a compromise or an incorrect action on its own.

3. Distinguishing situations where information is unavailable #

Missing reports, outdated content or insufficient information for verification do not prove that nothing is wrong. Whether observations are available is checked alongside the decision itself.

The emphasis is on making information gaps identifiable so that operators can review them and take appropriate action.

4. Checking impacts on legitimate use #

Even a defensive response can affect legitimate users or business operations if it is directed at the wrong target. It is important to define the response scope, how records are kept, and the procedures operators use to review and address the situation.

The scope of automation and the methods for necessary checks are considered according to the conditions of each deployment.

5. Separating operational records from evidence of protection #

We continue to improve BASTION while reviewing observations and response records from our own environment. However, the absence of observed anomalies or erroneous blocking alone does not establish how effective the defenses would be in the event of a compromise.

Verification is carried out according to the conditions of use, with a clear distinction between what has been verified and what remains unverified.

6. Deployment checks and the scope of public information #

Before deployment, we identify the information that can be obtained, connection requirements, permitted actions and operator review procedures. Configuration and evaluation scopes are quoted individually based on the target environment and requirements.

This article explains design principles. It does not disclose verification algorithms, control conditions, internal connection arrangements or customers’ operational information. Please see the BASTION service overview page for current capabilities and verification status.